Courseiva

CCNA Cloud Native Architecture Questions

37 questions · Cloud Native Architecture · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

You are implementing distributed tracing across multiple microservices running on OKE. You need to capture trace data from incoming API Gateway requests, through service mesh sidecars, down to the application pods, and export it to an open-standards tracing backend. Which architectural components should you configure?

A.Kubernetes Liveness probes configured with HTTP GET request headers.
B.OCI Audit log queries combined with Object Storage bucket lifecycle rules.
C.OCI Notifications service broadcast topics configured with JSON log forwarding.
D.W3C Trace Context header propagation across API Gateway, OCI Service Mesh Envoy proxies, and OpenTelemetry SDKs in applications.
AnswerD

W3C Trace Context propagation supplies the standardised `traceparent` header that links spans across every hop, satisfying the requirement to trace API Gateway requests through Envoy sidecars to application pods. OpenTelemetry SDKs export this data via OTLP to any open-standards backend, avoiding vendor-specific agents.

Why this answer

Distributed tracing across API Gateway, service mesh sidecars, and application pods requires a common trace context propagated end-to-end. The W3C Trace Context standard (traceparent/tracestate headers) is the open standard that API Gateway, OCI Service Mesh Envoy proxies, and OpenTelemetry SDKs all understand, allowing spans to be correlated and exported to any OpenTelemetry-compatible backend. This is the only option that describes an actual tracing architecture.

Exam trap

The trap is selecting log aggregation or audit services (Notifications, Audit, Object Storage) as if they provided tracing; the exam tests whether you know tracing requires W3C Trace Context propagation and OpenTelemetry, not logs.

How to eliminate wrong answers

Option A is wrong because Kubernetes liveness probes are health checks that restart unhealthy pods; HTTP GET headers on probes have nothing to do with trace context propagation. Option B is wrong because OCI Audit logs record control-plane API activity and Object Storage lifecycle rules manage object retention; neither captures or correlates distributed traces. Option C is wrong because OCI Notifications broadcasts messages to subscribers and JSON log forwarding is log shipping, not distributed trace context propagation across services.

Practice this question →
2
Multi-Selecthard

When designing an API Gateway implementation on OCI to expose backend microservices running on OKE, which THREE features or capabilities can you configure directly within the API Gateway deployment? (Choose three.)

Select 3 answers
A.Request throttling and rate-limiting to protect backend microservices from traffic surges.
B.Automatic multi-region database failover orchestration for Oracle Autonomous Database.
C.Cross-Origin Resource Sharing (CORS) policies to control browser-based access from web frontend applications.
D.JSON Web Token (JWT) validation for validating bearer tokens from identity providers.
E.Automatic provisioning and scaling of Kubernetes worker node pools inside OKE.
AnswersA, C, D

OCI API Gateway supports usage plans with request throttling and rate-limiting per client, enforced at the gateway before requests reach OKE backend microservices. This satisfies the requirement to protect backends from traffic surges without modifying application code.

Why this answer

Option A is correct because OCI API Gateway lets you define usage plans with request throttling and rate-limiting policies per deployment, protecting backend microservices on OKE from traffic surges. Option C is correct because API Gateway supports configuring CORS policies at the deployment level, allowing you to control which web frontend origins can make browser-based cross-origin requests to the API. Option D is correct because API Gateway can be configured with JWT authentication to validate bearer tokens issued by identity providers before forwarding requests to backend services.

Option B is not part of API Gateway's capabilities; Autonomous Database multi-region failover is handled by Data Guard and database-level services, not the gateway. Option E is also unrelated, since OKE worker node pool provisioning and scaling are managed through OKE node pools and the cluster autoscaler, not through API Gateway.

Exam trap

1Z0-997-26 often tests the boundary between API Gateway features and backend platform features — candidates must recognize that database failover and OKE node scaling are outside API Gateway's scope.

Practice this question →
3
MCQmedium

Your OKE cluster uses Calico for Kubernetes network policy enforcement. You need to write a network policy that allows Pod A in namespace 'frontend' to communicate with Pod B in namespace 'backend', while blocking all other ingress traffic to Pod B. How should you implement this?

A.Apply an OCI Identity and Access Management (IAM) policy restricting pod access.
B.Configure an OCI Load Balancer listener rule for namespace ports.
C.Create a Kubernetes NetworkPolicy in the 'backend' namespace selecting Pod B and allowing ingress exclusively from namespace 'frontend'.
D.Modify the VCN Security List for the worker node subnet to filter traffic by pod name.
AnswerC

Calico enforces standard Kubernetes NetworkPolicy objects, so a policy in the 'backend' namespace with podSelector matching Pod B and an ingress rule using namespaceSelector for 'frontend' permits only that traffic. Because NetworkPolicy is default-deny once a pod is selected, all other ingress to Pod B is blocked, satisfying the isolation requirement.

Why this answer

A Kubernetes NetworkPolicy in the 'backend' namespace that selects Pod B and allows ingress only from namespace 'frontend' is the correct Calico-enforced approach. NetworkPolicies are namespace-scoped, select pods by labels, and define allowed ingress/egress, which is exactly what is needed to permit frontend-to-backend while blocking all other ingress.

Exam trap

1Z0-997-26 often tests the misconception that OCI IAM, VCN Security Lists, or Load Balancer rules can enforce Kubernetes pod-level network policy — candidates must recognize that only a CNI-enforced NetworkPolicy (Calico) operates at the pod label/namespace level.

How to eliminate wrong answers

Option A is wrong because OCI IAM policies govern OCI API access, not pod-to-pod network traffic inside the cluster. Option B is wrong because an OCI Load Balancer listener rule operates at L4/L7 for external traffic, not for intra-cluster pod-to-pod policy enforcement. Option D is wrong because VCN Security Lists filter at the subnet/ENI level by IP and port, not by Kubernetes pod name or namespace labels.

Practice this question →
4
MCQeasy

Your OCI Function needs to write audit logs or custom debugging information that can be easily searched and analyzed alongside other cloud logs. Which OCI service should your function log to?

A.OCI Logging Service
B.OCI DNS Service
C.OCI Vault
D.OCI Email Delivery Service
AnswerA

OCI Logging Service ingests custom function output through the unified agent or SDK, storing it in log groups that support search, filtering, and correlation with other OCI logs. This satisfies the stem's requirement that debugging information be searchable alongside existing cloud logs, which Object Storage or Notifications cannot provide.

Why this answer

OCI Logging Service is the correct choice because it is a fully managed, scalable service that ingests, aggregates, and indexes log data from various OCI resources, including Functions. It allows you to search, analyze, and correlate logs across services, and supports custom logs from serverless functions. By logging to OCI Logging, the function's audit and debug information becomes part of the centralized logging platform, enabling easy querying and integration with other cloud logs.

Exam trap

The trap here is confusing OCI Logging with other services that handle data (like Vault for secrets or Email Delivery for notifications), but only Logging is designed for searchable, analyzable log data.

How to eliminate wrong answers

Option B is wrong because OCI DNS Service is a domain name system management service, not a logging or audit service; it does not store or index application logs. Option C is wrong because OCI Vault is a key management and secrets storage service, designed to securely store encryption keys and secrets, not to collect or analyze log data. Option D is wrong because OCI Email Delivery Service is used to send bulk or transactional emails, not to store or search logs; it lacks log aggregation and analysis capabilities.

Practice this question →
5
MCQmedium

You are troubleshooting an OCI Functions application that fails to pull container images from a private Oracle Cloud Infrastructure Registry (OCIR) repository during deployment. The function application is configured correctly, but the build/invoke fails with authentication errors. What is the most likely missing configuration?

A.The OCI VCN Security List lacks an egress rule for port 22 to connect to GitHub.
B.Missing IAM policy granting the Functions service or dynamic group read access to the OCIR repository compartment.
C.The API Gateway deployment lacks a public IP address.
D.The OCI Vault master encryption key is disabled.
AnswerB

Pulling images from a private OCIR repository requires an IAM policy letting the Functions dynamic group read that compartment's repositories. Without it, the service principal cannot authenticate, producing the observed image-pull authentication failures during build or invoke.

Why this answer

OCI Functions pulls container images from OCIR using the function's resource principal, which is derived from the dynamic group membership of the function application. Without an IAM policy that grants this dynamic group (or the Functions service) permission to read the OCIR repository compartment, the pull fails with an authentication error. The policy must explicitly allow the dynamic group to read repos in the compartment where the OCIR repository resides.

Exam trap

1Z0-997-26 often tests the misconception that OCI Functions uses SSH or API Gateway for image pulls, when in fact it relies on IAM policies and dynamic groups for OCIR authentication.

How to eliminate wrong answers

Option A is wrong because OCI Functions does not use SSH (port 22) to pull images from OCIR; it uses the OCI API over HTTPS (port 443), and GitHub connectivity is irrelevant to OCIR authentication. Option C is wrong because API Gateway is not involved in the function's image pull process; the function runtime pulls the image directly from OCIR, and API Gateway public IP has no bearing on authentication. Option D is wrong because a disabled Vault master encryption key would affect access to secrets or encrypted data, not the authentication to OCIR; OCIR authentication relies on IAM policies and resource principals, not Vault keys.

Practice this question →
6
MCQhard

Your microservices architecture on OKE uses mTLS (Mutual TLS) for secure pod-to-pod communication. You notice that certificate rotation is causing intermittent connection drops because pods are not reloading the new certificates without a restart. Which OCI Service Mesh feature automatically manages certificate issuance and rotation without requiring pod restarts?

A.OCI Certbot DaemonSet running on all worker nodes
B.OCI Vault automatic key version rotation
C.OCI Service Mesh automated certificate management with Envoy sidecar proxy hot-reload
D.Kubernetes CronJob executing kubectl rollout restart every night
AnswerC

Envoy sidecar hot-reload lets the proxy pick up rotated certificates via its SDS (Secret Discovery Service) API without terminating the pod, so existing connections drain gracefully rather than dropping. This directly satisfies the stem's constraint that rotation must occur without pod restarts.

Why this answer

OCI Service Mesh uses an Envoy sidecar proxy injected into each pod, and its control plane (based on Istio) performs automated certificate management — issuing, rotating, and hot-reloading X.509 certificates via the Envoy SDS (Secret Discovery Service) API without restarting the pod or the proxy. This eliminates the connection drops caused by stale certificates, since the sidecar picks up the new cert in-memory.

Exam trap

The trap here is confusing generic secret-management services (OCI Vault, Certbot) with mesh-native identity management — candidates pick Vault because it 'rotates keys,' but only the mesh control plane can hot-reload Envoy sidecar certs without a restart.

How to eliminate wrong answers

Option A is wrong because Certbot is a Let's Encrypt/ACME client for public web certificates, not an OCI-native mesh component, and a DaemonSet cannot inject per-pod mTLS identities or hot-reload Envoy. Option B is wrong because OCI Vault rotates key versions for secrets/encryption keys but does not push rotated certs into running Envoy sidecars or manage SPIFFE identities. Option D is wrong because a nightly CronJob that restarts pods is disruptive, causes downtime, and does not provide automatic rotation — it is a manual workaround, not a mesh feature.

Practice this question →
7
MCQhard

You are designing a disaster recovery strategy for a stateful microservices application running on OKE across two OCI regions. Persistent data is stored on OCI Block Volumes. What is the recommended approach to replicate persistent storage data across regions for stateful workloads?

A.Configure cross-region block volume asynchronous replication to the secondary region.
B.Rely on Kubernetes Persistent Volume snapshots stored locally on worker node local NVMe drives.
C.Attach the same Block Volume simultaneously to worker nodes in both regions across the VCN peering.
D.Use OCI Streaming to replicate raw block storage disk sectors.
AnswerA

Cross-region block volume asynchronous replication continuously copies volume data to a secondary region, giving stateful OKE workloads a recoverable copy without synchronous latency penalties. On failover, replicated volumes are activated in the secondary region and reattached to the cluster.

Why this answer

Cross-region asynchronous block volume replication is the native OCI feature designed to copy Block Volume data from a primary region to a secondary region for DR. It continuously replicates volume data at the block level, so stateful workloads on OKE can fail over and reattach replicated volumes in the secondary region. This is the recommended, supported approach for cross-region persistence in OCI.

Exam trap

1Z0-997-26 often tests whether candidates confuse block-level replication with application-level or message-bus replication — the trap is picking OCI Streaming or local NVMe snapshots as if they provided cross-region durability for Block Volumes.

How to eliminate wrong answers

Option B is wrong because PV snapshots stored on worker node local NVMe are node-local, ephemeral, and not replicated across regions — losing the node loses the data. Option C is wrong because an OCI Block Volume cannot be simultaneously attached to worker nodes in two different regions; Block Volumes are zonal resources with single-attach semantics (or multi-attach only within the same AD for specific volume types). Option D is wrong because OCI Streaming is a Kafka-compatible message bus, not a block-level storage replication mechanism — it cannot replicate raw disk sectors.

Practice this question →
8
Multi-Selecteasy

Which TWO methods can developers use to interact with OCI Registry (OCIR) for pushing and pulling container images?

Select 2 answers
A.Docker CLI authenticated with an OCI Auth Token
B.Podman CLI authenticated with OCI credentials
C.Windows Remote Desktop (RDP) file transfer
D.Kubernetes kubelet raw disk mounting
E.Direct FTP client over port 21
AnswersA, B

The Docker CLI, authenticated with an OCI Auth Token, is a supported method for pushing and pulling images to OCIR. The token replaces the password during docker login against the regional registry endpoint, satisfying the requirement for a native developer interaction method.

Why this answer

Option A is correct because the Docker CLI is a standard, supported client for OCIR: after running `docker login <region-key>.ocir.io` with the OCI username (tenancy namespace/username) and an OCI Auth Token as the password, developers can `docker push` and `docker pull` images against OCIR repositories. Option B is correct because Podman is also a fully supported OCI-compliant container client; authenticating with OCI credentials (username plus Auth Token) via `podman login <region-key>.ocir.io` allows the same push and pull operations against OCIR. The remaining options do not belong: RDP is a remote desktop protocol for GUI sessions, not an image registry transport; kubelet raw disk mounting is not a registry interaction method and kubelet pulls images via container runtime credentials rather than mounting disks; and FTP over port 21 is a legacy file-transfer protocol that OCIR does not expose for container image push/pull operations.

Exam trap

1Z0-997-26 often tests whether candidates know OCIR is Docker V2-compatible and authenticated via OCI Auth Tokens, luring them toward generic file-transfer or Kubernetes-internal mechanisms that have nothing to do with registry operations.

Practice this question →
9
MCQhard

An OCI Function in your serverless architecture needs to process large files (up to 5GB) uploaded to an OCI Object Storage bucket. Due to ephemeral storage limits inside the function container (/tmp), the function crashes when attempting to download the entire file locally. How should you redesign this function processing flow?

A.Attach an OCI Block Volume directly to the OCI Function container instance.
B.Increase the OCI Function memory allocation to automatically provision a larger /tmp filesystem.
C.Stream the file contents in chunks using Object Storage API range requests and process data iteratively without full local storage.
D.Mount an OCI File Storage Service (FSS) target over the internet inside the function code.
AnswerC

Object Storage supports HTTP range requests, letting the function fetch defined byte ranges sequentially rather than the whole 5GB object. Processing each chunk iteratively keeps memory and /tmp usage bounded, avoiding the container crash caused by full local download.

Why this answer

Streaming the file in chunks using Object Storage API range requests allows the function to process data iteratively without storing the entire 5GB file locally, staying within the /tmp ephemeral storage limit. This is the recommended serverless pattern for large files, as it avoids memory and disk exhaustion.

Exam trap

1Z0-997-26 often tests the misconception that increasing function memory also increases /tmp storage, leading candidates to choose the memory option instead of implementing chunked streaming.

How to eliminate wrong answers

Option A is wrong because OCI Functions cannot attach OCI Block Volumes directly to their container instances; they are ephemeral and stateless. Option B is wrong because increasing memory allocation does not automatically provision a larger /tmp filesystem; /tmp is fixed and ephemeral. Option D is wrong because mounting OCI File Storage Service over the internet inside the function is not supported, insecure, and impractical for serverless containers.

Practice this question →
10
MCQmedium

Your serverless OCI Function written in Python is failing to process payloads because it exceeds the default execution timeout limit when calling a third-party REST API. How should you resolve this issue while adhering to best practices?

A.Increase the memory allocation to automatically and proportionally increase the timeout limit.
B.Deploy the function behind an OCI Load Balancer to cache timeout requests.
C.Upgrade the underlying OCI Compute shape of the worker nodes in OKE.
D.Modify the function timeout configuration using the Fn Project CLI or OCI Console to a higher value up to the service limit.
AnswerD

Raising the function timeout via the Fn Project CLI or OCI Console directly addresses the exceeded execution limit, allowing the third-party REST API call to complete. OCI Functions permits timeouts up to 300 seconds, so increasing the configured value within that service ceiling resolves the failure without altering application logic.

Why this answer

OCI Functions allow you to configure the function timeout up to the service limit (default 30 seconds, maximum 300 seconds) via the Fn Project CLI or OCI Console. Increasing the timeout directly addresses the failure when calling a slow third-party REST API, and is the recommended best practice for long-running calls.

Exam trap

1Z0-997-26 often tests the misconception that memory allocation and timeout are linked in OCI Functions, leading candidates to choose the memory option instead of explicitly configuring the timeout.

How to eliminate wrong answers

Option A is wrong because increasing memory allocation does not proportionally increase the timeout limit in OCI Functions; timeout is a separate configuration parameter. Option B is wrong because an OCI Load Balancer cannot cache or extend function execution timeouts; it only distributes incoming traffic. Option C is wrong because OCI Functions run on managed infrastructure, not on OKE worker nodes, so upgrading compute shapes is irrelevant.

Practice this question →
11
Multi-Selecthard

You are designing an OKE-based cloud-native microservices architecture and want to ensure high availability and robust security isolation. Which THREE architectural best practices should you implement?

Select 3 answers
A.Enable private Kubernetes API server endpoint access so the control plane is not exposed publicly.
B.Deploy worker nodes in private subnets with no direct public IP addresses.
C.Distribute OKE worker node pools across multiple Fault Domains or Availability Domains within the region.
D.Disable all Kubernetes RBAC authorization to allow unrestricted developer deployments.
E.Run all Kubernetes system pods and application workloads in the 'default' namespace as root user.
AnswersA, B, C

A private Kubernetes API endpoint keeps the control plane off the public internet, so only hosts with VCN access can reach it. This directly enforces the security isolation the architecture demands, removing an externally reachable attack surface.

Why this answer

Option A is correct because enabling a private Kubernetes API server endpoint in OKE ensures the control plane is only reachable through the VCN (via private IPs, VPN, FastConnect, or bastion), removing public internet exposure and reducing the attack surface for the cluster's management plane. Option B is correct because placing worker nodes in private subnets with no public IPs prevents direct inbound internet access to nodes, forcing traffic through controlled ingress (load balancers, NAT gateway for egress), which enforces network isolation and least-privilege connectivity. Option C is correct because spreading worker node pools across multiple Fault Domains or Availability Domains within the region provides fault tolerance against AD/FD-level failures, so the loss of one domain does not take down all worker capacity and preserves high availability.

Option D is incorrect because disabling Kubernetes RBAC removes authorization controls, granting unrestricted access and violating the security isolation requirement rather than improving it. Option E is incorrect because running all system pods and workloads in the default namespace as root eliminates namespace-based isolation and least-privilege execution, which are core security best practices for multi-tenant or microservices architectures.

Exam trap

1Z0-997-26 often tests whether candidates recognize that security best practices include private endpoints and RBAC, not disabling RBAC or using the default namespace as root, so the trap is selecting convenience-oriented options that weaken security.

Practice this question →
12
MCQhard

You are designing a multi-tenant microservices platform on OKE. You need to ensure that tenant workloads are strictly isolated at the kernel level, preventing potential container breakout vulnerabilities from affecting other tenants. Which OCI Container Engine for Kubernetes node configuration should you choose?

A.Worker nodes utilizing Kata Containers runtime for hardware-level isolation
B.Standard OKE worker nodes with Kubernetes LimitRanges
C.Standard worker nodes with Network Security Groups (NSGs) applied per pod
D.Worker nodes running Docker Engine with privileged containers enabled
AnswerA

Kata Containers runs each pod inside a lightweight virtual machine, giving hardware-enforced kernel separation rather than the shared kernel of runc. This directly satisfies the stem's requirement for kernel-level isolation between tenants, containing any container breakout to its own guest kernel and preventing cross-tenant impact on the OKE worker nodes.

Why this answer

Kata Containers provide hardware-level isolation by running each container inside a lightweight virtual machine with its own kernel, so a container breakout affects only that VM and cannot compromise other tenants. This is the correct choice when strict kernel-level isolation is required on OKE.

Exam trap

1Z0-997-26 often tests whether candidates confuse network isolation (NSGs) or resource quotas (LimitRanges) with kernel-level isolation, so the trap is picking a network or quota control when the question explicitly demands protection against container breakout.

How to eliminate wrong answers

Option B is wrong because LimitRanges only enforce CPU and memory quotas per namespace or pod; they do not provide kernel-level isolation and do nothing to prevent container breakout. Option C is wrong because Network Security Groups applied per pod control network traffic, not kernel isolation, so a breakout could still affect other tenants on the same node. Option D is wrong because running Docker Engine with privileged containers actually weakens isolation by granting containers elevated host access, which is the opposite of the requirement.

Practice this question →
13
MCQeasy

An architect is designing a cloud-native application that must remain available if an entire OCI region becomes unavailable. The application uses OCI Object Storage for static assets and an Autonomous Database for transactional data. Which approach best meets the cross-region availability requirement?

A.Enable Object Storage replication to a bucket in a second region, and configure Autonomous Database cross-region disaster recovery with a standby in that region.
B.Enable Object Storage versioning and take daily Autonomous Database backups to a bucket in the same region.
C.Configure a load balancer across two availability domains in the primary region and enable health checks on the backend services.
D.Use OCI Block Volume backups replicated within the same availability domain and rely on the Autonomous Database's automatic backups.
AnswerA

Object Storage replication copies objects to a bucket in another region, and Autonomous Database supports cross-region disaster recovery with a standby that can be promoted. Together they provide data durability and availability across regions, directly addressing the requirement to survive a full region outage with minimal data loss.

Why this answer

Surviving a full region outage requires data and services to exist in another region. Object Storage replication maintains a copy of static assets in a second region, and Autonomous Database cross-region disaster recovery provides a promotable standby. Load balancing or versioning within one region cannot preserve availability when that region fails, so the cross-region replication approach is required.

Exam trap

The trap here is confusing high availability within a region, such as multi-AD load balancing or versioning, with cross-region disaster recovery that can survive the loss of an entire region.

Practice this question →
14
MCQeasy

You need to store sensitive configuration data, such as database connection strings and API keys, for your OCI Functions application. Where should you securely store these values so they can be injected as environment variables or retrieved securely?

A.OCI Object Storage public bucket
B.OCI Audit log retention policy
C.OCI Resource Manager stack configuration output
D.OCI Vault (Secrets management)
AnswerD

OCI Vault's secrets management stores credentials encrypted with keys held in a hardware security module, and Functions can retrieve them at runtime through the Vault API or inject them as environment variables via configuration. This satisfies the requirement to keep connection strings and API keys out of plaintext function configuration.

Why this answer

OCI Vault's Secrets management feature is designed to store sensitive values like database connection strings and API keys, and OCI Functions can retrieve them securely at runtime via the OCI SDK or by referencing them as environment variables. This keeps secrets encrypted and access-controlled through IAM policies.

Exam trap

1Z0-997-26 often tests whether candidates confuse general storage or logging services with a dedicated secret store, so the trap is picking Object Storage or Resource Manager outputs when the requirement is secure, access-controlled secret storage.

How to eliminate wrong answers

Option A is wrong because an Object Storage public bucket exposes data to anyone with the URL, which is the opposite of secure storage for sensitive configuration. Option B is wrong because Audit log retention policy governs how long audit logs are kept, not where application secrets are stored. Option C is wrong because Resource Manager stack configuration outputs are meant for infrastructure-as-code outputs and are not a secure secret store; they may be visible in state files and logs.

Practice this question →
15
Multi-Selecteasy

Which TWO of the following are key architectural benefits of adopting serverless OCI Functions compared to managing traditional container clusters for event-driven tasks?

Select 2 answers
A.Built-in requirement to configure manual Kubernetes Horizontal Pod Autoscalers
B.Guaranteed permanent container warm-start memory caching with zero cold starts ever
C.Full administrative root access to the underlying hypervisor and host operating system kernel
D.Automatic scaling from zero to thousands of executions based on incoming events without managing servers
E.Pay-as-you-go pricing model where you only pay for the exact execution time consumed down to the millisecond
AnswersD, E

OCI Functions scales elastically from zero to thousands of concurrent executions as events arrive, removing node provisioning, cluster capacity planning and idle worker management. That directly addresses the event-driven scenario where demand is sporadic and unpredictable.

Why this answer

Option D is correct because OCI Functions is a fully managed FaaS platform that automatically scales the function fleet from zero to thousands of concurrent executions in response to incoming events, eliminating the need to provision, patch, or manage any servers or worker nodes. Option E is correct because OCI Functions bills on a pay-as-you-go model based on actual execution time measured in milliseconds (plus invocation counts and provisioned resources), so you pay only for the compute actually consumed rather than for idle cluster capacity. Option A is incorrect because manual Kubernetes Horizontal Pod Autoscalers are a container-cluster concern; serverless functions abstract away pod and HPA management entirely.

Option B is incorrect because no serverless platform guarantees permanent warm containers or zero cold starts; cold starts can still occur when scaling from zero. Option C is incorrect because serverless platforms deliberately hide the underlying hypervisor and host OS kernel, providing no root administrative access to that infrastructure.

Exam trap

1Z0-997-26 often tests serverless benefits, and candidates may incorrectly select options that describe container cluster management tasks or unrealistic guarantees like zero cold starts.

Practice this question →
16
MCQeasy

You need to trigger an OCI Function asynchronously whenever an object is uploaded to an OCI Object Storage bucket. Which OCI service acts as the event router between Object Storage and the Function?

A.OCI DNS
B.OCI Events Service
C.OCI File Storage Service
D.OCI Data Transfer Service
AnswerB

OCI Events Service matches the Object Storage object-creation event against a rule and invokes the Function as the action. It is the event router connecting the bucket to the Function, satisfying the asynchronous trigger requirement.

Why this answer

OCI Events Service is the native event-routing service in OCI that listens to Object Storage bucket events (such as ObjectCreate) and delivers them to targets like OCI Functions, Notifications, or Streaming. When an object is uploaded, Object Storage emits an event to the Events Service, which matches it against a rule and invokes the Function asynchronously. This decouples the storage layer from the compute layer and is the standard serverless event-driven pattern in OCI.

Exam trap

The trap here is confusing OCI DNS or Data Transfer with event-driven integration; candidates who haven't used OCI Events Service may pick a service that sounds like it 'moves' or 'routes' data rather than the actual event router.

How to eliminate wrong answers

Option A is wrong because OCI DNS is a domain name resolution and traffic management service; it has no event subscription or routing capability toward Functions. Option C is wrong because OCI File Storage Service provides NFS-based shared file systems and does not emit object-upload events or route them to Functions. Option D is wrong because OCI Data Transfer Service is used for bulk data movement (appliances, disks, or over the network) and is not an event router.

Practice this question →
17
Multi-Selecteasy

Which TWO of the following are valid methods to trigger an OCI Function execution?

Select 2 answers
A.OCI Identity and Access Management password rotation policy
B.OCI Events Service rule reacting to object storage or compute state changes
C.Direct physical USB drive insertion into OCI Exadata infrastructure
D.HTTP requests routed through OCI API Gateway
E.OCI Block Volume disk defragmentation schedule
AnswersB, D

OCI Events Service rules evaluate resource state changes, such as object creation in Object Storage or compute instance lifecycle transitions, and invoke a Function as the rule's action. This satisfies the stem's requirement for an event-driven trigger rather than a manual or scheduled invocation path.

Why this answer

Option B is correct because the OCI Events Service can publish events (for example, Object Storage object-create or Compute instance state-change events) that match a rule and invoke a Function as the rule's action, making event-driven invocation a valid trigger method. Option D is correct because OCI Functions can be exposed as HTTP endpoints, and OCI API Gateway can route incoming HTTP requests to a Function, so client HTTP calls through the gateway trigger function execution. Option A is not a trigger: IAM password rotation policy is an identity/security governance setting and does not invoke Functions.

Option C is not a trigger: physically inserting a USB drive into Exadata infrastructure is not an OCI control-plane or event mechanism for Functions. Option E is not a trigger: Block Volume defragmentation scheduling is a storage maintenance operation and does not invoke Functions.

Exam trap

1Z0-997-26 often tests whether candidates know the actual OCI event sources and invocation mechanisms for Functions, tempting them with unrelated services like IAM policies or storage maintenance tasks that sound plausible but have no trigger integration.

Practice this question →
18
MCQmedium

Your OKE cluster is running microservices that require rapid horizontal scaling based on custom application metrics (such as active queue length) rather than standard CPU or memory utilization. Which Kubernetes component should you deploy to achieve this?

A.Kubernetes Vertical Pod Autoscaler (VPA) with static CPU limits
B.OCI Autoscaling for OKE worker nodes
C.Kubernetes Horizontal Pod Autoscaler (HPA) integrated with Prometheus and Prometheus Adapter
D.OCI Instance Pool autoscaling configuration
AnswerC

HPA scales pods, but custom metrics such as active queue length require the Prometheus Adapter to expose them through the custom metrics API. HPA then reads those metrics, satisfying the requirement for scaling on application metrics rather than CPU or memory.

Why this answer

The Kubernetes Horizontal Pod Autoscaler (HPA) can scale pods based on custom metrics when integrated with Prometheus and the Prometheus Adapter. The adapter exposes custom metrics from Prometheus to the Kubernetes metrics API, allowing HPA to query metrics like active queue length and scale accordingly. This is the standard approach for custom metric-based autoscaling in OKE.

Exam trap

1Z0-997-26 often tests the difference between pod-level and node-level autoscaling, and candidates may confuse HPA with VPA or node pool autoscaling, especially when custom metrics are involved.

How to eliminate wrong answers

Option A is wrong because Vertical Pod Autoscaler adjusts CPU and memory requests/limits for pods, not horizontal scaling, and it does not support custom metrics like queue length. Option B is wrong because OCI Autoscaling for OKE worker nodes scales the number of nodes in a node pool, not the number of pods, and it is based on node pool metrics, not application-specific custom metrics. Option D is wrong because OCI Instance Pool autoscaling also scales compute instances, not pods, and is not integrated with Kubernetes custom metrics.

Practice this question →
19
MCQeasy

You need to secure your OCI API Gateway deployment by ensuring that only authenticated requests containing a valid JSON Web Token (JWT) issued by an identity provider can access your backend microservices. Which API Gateway feature should you implement?

A.OCI Identity and Access Management (IAM) dynamic groups
B.Network Security Group (NSG) ingress rules on the API Gateway subnet
C.Authentication policy using JWT validation
D.OCI Web Application Firewall (WAF) rate limiting rule
AnswerC

A JWT authentication policy makes the gateway validate the token's signature, issuer, audience and expiry against the identity provider's keys before forwarding. Requests lacking a valid JWT are rejected at the gateway, so backend microservices never receive unauthenticated traffic.

Why this answer

OCI API Gateway supports authentication policies that can validate JSON Web Tokens (JWT) issued by an identity provider before forwarding requests to backend services. Configuring a JWT validation authentication policy ensures only requests with a valid, unexpired token from the trusted issuer reach the microservices. This is the native, purpose-built feature for token-based API authentication.

Exam trap

1Z0-997-26 often tests whether candidates confuse network-layer controls (NSGs, WAF) with application-layer authentication (JWT policies), leading them to pick NSG or WAF when token validation is required.

How to eliminate wrong answers

Option A is wrong because IAM dynamic groups are used to grant OCI resources (like compute instances or functions) permissions to call OCI services, not to validate JWTs on incoming API requests. Option B is wrong because NSG ingress rules operate at the network layer (IP/port filtering) and cannot inspect or validate JWT tokens in HTTP headers. Option D is wrong because WAF rate limiting controls request volume to mitigate abuse or DoS, but does not perform JWT authentication or authorization.

Practice this question →
20
Multi-Selecthard

You are implementing zero-trust network security for an OKE microservices application using OCI Service Mesh. Which THREE capabilities does OCI Service Mesh provide to secure service-to-service communication?

Select 3 answers
A.Telemetry data collection including latency, error rates, and request volume metrics
B.Access control policies to restrict which services can communicate with each other
C.Automatic mutual TLS (mTLS) encryption for in-transit pod-to-pod communication
D.Direct hardware firewall ACL programming on physical Oracle Exadata rack switches
E.Automatic translation of Oracle Database PL/SQL stored procedures into REST APIs
AnswersA, B, C

OCI Service Mesh's sidecar proxies emit telemetry covering latency, error rates and request volume, giving the observability needed to detect anomalous service-to-service behaviour. This visibility underpins zero-trust monitoring, complementing the mesh's mTLS and authorisation controls rather than replacing them.

Why this answer

OCI Service Mesh is built on an Istio-based sidecar architecture and provides three core zero-trust capabilities for service-to-service communication. Option A is correct because the mesh's sidecar proxies emit telemetry such as latency, error rates, and request volume metrics (via Prometheus/OCI Monitoring), giving observability into microservice traffic. Option B is correct because OCI Service Mesh enforces access control policies (AuthorizationPolicy) that define which service identities may communicate with which services, supporting least-privilege zero-trust segmentation.

Option C is correct because the mesh automatically provisions and rotates mutual TLS (mTLS) certificates for pod-to-pod traffic, encrypting all in-transit service communication without application changes. Option D is incorrect because OCI Service Mesh operates at the Kubernetes/Istio layer and does not program physical Exadata rack switch ACLs. Option E is incorrect because translating PL/SQL stored procedures into REST APIs is not a Service Mesh function; that would require a separate API gateway or ORDS-style tooling.

Exam trap

1Z0-997-26 often tests whether candidates confuse OCI Service Mesh's Istio-based L7 capabilities (mTLS, authorization policies, telemetry) with unrelated OCI services like ORDS or physical network controls, so distractors that sound 'infrastructure-y' or 'database-y' are designed to lure candidates away from the three genuine mesh features.

Practice this question →
21
MCQeasy

You are deploying a microservices application on Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). You need to expose multiple internal services externally using a single public IP address and enforce URL path-based routing. Which OCI networking and container component should you use?

A.OCI File Storage Service mounted on all worker nodes
B.Kubernetes NodePort service directly pointing to every individual pod
C.OCI API Gateway without any OKE Ingress
D.OCI Native Ingress Controller configured with an OCI Load Balancer
AnswerD

The OCI Native Ingress Controller provisions an OCI Load Balancer with a single public IP and translates Kubernetes Ingress path rules into listener routing, satisfying both the single-IP and URL path-based routing constraints for the internal services.

Why this answer

The OCI Native Ingress Controller integrates with OCI Load Balancer to provision a single public load balancer with one public IP, and it supports Kubernetes Ingress rules including URL path-based routing to backend services. This is the standard OKE pattern for exposing multiple internal services externally through one entry point with path-based routing.

Exam trap

1Z0-997-26 often tests whether candidates know that OKE ingress requires the OCI Native Ingress Controller plus an OCI Load Balancer, luring them toward NodePort or API Gateway as if they provided native Kubernetes path-based routing.

How to eliminate wrong answers

Option A is wrong because File Storage Service is a shared NFS filesystem for pods, not an ingress or routing component. Option B is wrong because NodePort exposes a service on every node's IP and a high port, not a single public IP, and it does not provide URL path-based routing. Option C is wrong because API Gateway alone does not integrate with OKE Ingress resources and would require manual backend configuration rather than native Kubernetes Ingress semantics.

Practice this question →
22
MCQhard

You are architecting a multi-region cloud-native application where OCI API Gateway is deployed in Region A and Region B. You need to ensure that global users are automatically routed to the closest healthy API Gateway endpoint with automatic failover if an entire OCI region experiences an outage. Which OCI service should you use in front of the API Gateways?

A.OCI File Storage cross-region replication
B.OCI DNS Traffic Management Steering with Failover and Health Checks
C.OCI Bastion Service in the primary region
D.OCI Local VCN Peering across regions
AnswerB

DNS Traffic Management Steering with health checks resolves users to the nearest healthy API Gateway and automatically withdraws failed regional endpoints, delivering latency-based routing plus region-level failover. This satisfies the requirement for closest-endpoint routing with automatic failover during an entire OCI region outage.

Why this answer

OCI Traffic Management (or OCI DNS Traffic Management / Global Load Balancing) routes users across multiple regions based on latency, geo-location, or failover policies.

Practice this question →
23
MCQhard

You are managing an enterprise OKE cluster that runs multi-tenant workloads. Certain sensitive pods must run on dedicated worker nodes to comply with strict isolation mandates. Which combination of Kubernetes scheduling features should you configure on OCI to enforce this requirement reliably?

A.Kubernetes Taints, Tolerations, and Node Affinity
B.OCI Identity and Access Management (IAM) dynamic groups and compartment isolation
C.Kubernetes Horizontal Pod Autoscaler (HPA) and OCI Cluster Autoscaler
D.OCI Load Balancer flexible shapes and backend set weights
AnswerA

Taints on dedicated nodes repel pods lacking matching tolerations, while node affinity attracts sensitive pods to those labelled nodes. Combined, they guarantee sensitive workloads land only on isolated workers, satisfying the strict isolation mandate reliably rather than relying on scheduling chance.

Why this answer

Taints repel pods from nodes unless the pod has a matching toleration, and Node Affinity (specifically nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution) pins pods to nodes with specific labels. Combining taints on the dedicated nodes with tolerations on the sensitive pods, plus node affinity to select those labeled nodes, guarantees that only the intended sensitive workloads land on the dedicated worker nodes. This is the canonical Kubernetes pattern for hard multi-tenant isolation at the scheduling layer.

Exam trap

1Z0-997-26 often tests whether candidates conflate OCI IAM/compartment isolation (control-plane access) with Kubernetes scheduling controls (data-plane placement), so the trap is picking an IAM-based answer when the question is really about pod-to-node placement.

How to eliminate wrong answers

Option B is wrong because IAM dynamic groups and compartment isolation control OCI API-level access to resources (who can create/modify clusters, nodes, etc.) — they do not influence Kubernetes pod scheduling decisions, so a sensitive pod could still be scheduled onto a shared node. Option C is wrong because HPA scales pod replicas based on metrics and Cluster Autoscaler adds/removes nodes based on pending pods; neither enforces which node a given pod runs on, so they cannot provide tenant isolation. Option D is wrong because OCI Load Balancer shapes and backend weights control traffic distribution at L4/L7, not pod placement — they have no bearing on which worker node runs a pod.

Practice this question →
24
Multi-Selecteasy

Which TWO characteristics distinguish OCI Container Engine for Kubernetes (OKE) as a managed Kubernetes service?

Select 2 answers
A.Users have full administrative SSH access to the underlying Kubernetes master control plane nodes.
B.OKE automatically provisions Oracle Autonomous Databases for every deployed pod.
C.Users manage and control the worker node pools (compute shapes, scaling, OS patches).
D.Oracle manages and patches the Kubernetes control plane (master nodes) at no additional charge.
E.Kubernetes worker nodes are billed at a flat hourly rate regardless of compute shape.
AnswersC, D

OKE's shared-responsibility model leaves worker node pools under customer control: you choose compute shapes, configure scaling, and apply OS patches. This distinguishes the managed service from fully managed alternatives, since Oracle handles only the control plane while node lifecycle remains your operational responsibility.

Why this answer

Option D is correct because OKE is a managed Kubernetes service in which Oracle owns, runs, and patches the Kubernetes control plane (API server, etcd, scheduler, controller manager) and does not charge for those master nodes — customers pay only for the worker nodes and other resources they consume. Option C is correct because, while the control plane is managed by Oracle, the worker node pools remain the customer's responsibility: you choose compute shapes, node counts, autoscaling, and OS/image patching for the worker nodes. Option A is wrong because OKE does not grant users SSH administrative access to the Oracle-managed control plane master nodes; that access is restricted to Oracle.

Option B is wrong because OKE does not automatically provision Oracle Autonomous Databases for pods; persistent storage must be configured explicitly (for example, via OCI Block Volume or File Storage CSI drivers). Option E is wrong because worker nodes are billed based on the actual compute shape and resources used, not a flat hourly rate independent of shape.

Exam trap

1Z0-997-26 often tests the shared-responsibility boundary in managed Kubernetes, tricking candidates into assuming they get root access to the control plane or that Oracle manages worker nodes too.

Practice this question →
25
Multi-Selectmedium

When configuring OCI API Gateway, which THREE types of backends are natively supported for routing incoming API requests?

Select 3 answers
A.OCI Functions backend
B.HTTP/HTTPS URL backend
C.Stock Response (Mock) backend
D.OCI Identity Domain SAML federation metadata XML file store
E.Direct raw magnetic tape drive backup backend
AnswersA, B, C

OCI Functions backends let API Gateway invoke serverless functions directly, satisfying the requirement for natively supported routing targets. The gateway handles authentication and request transformation to the function endpoint, so no additional compute layer is needed. This is one of the three native backend types, alongside HTTP and OCI Streaming.

Why this answer

OCI API Gateway natively supports three backend types for routing API requests: OCI Functions backend (A), which lets a route invoke a serverless function in OCI Functions as the API's origin; HTTP/HTTPS URL backend (B), which forwards requests to an external or internal web server via a standard URL; and Stock Response (Mock) backend (C), which returns a predefined static response without contacting any origin, useful for testing or stubbing. These are the documented backend options available when creating a route in an API Gateway deployment. Option D is incorrect because Identity Domain SAML federation metadata XML is an identity/authentication artifact, not a routable API backend.

Option E is incorrect because raw magnetic tape drive backup is not a supported API Gateway backend type and is unrelated to API request routing.

Exam trap

1Z0-997-26 often tests whether candidates assume API Gateway can route to any OCI service (Object Storage, Identity Domains, tape) when only three backend types are native, so the trap is picking a plausible but unsupported backend.

Practice this question →
26
MCQeasy

You have deployed an OCI Function and want to test its HTTP trigger endpoint without writing custom client code. Which OCI service or feature should you use to invoke the function directly via an HTTP URL?

A.OCI API Gateway route pointing to the OCI Function
B.OCI Object Storage pre-authenticated request (PAR)
C.OCI Cloud Guard trigger policy
D.OCI Streaming cursor initialization
AnswerA

An OCI API Gateway route can target an OCI Function as its backend, exposing a public HTTP URL that invokes the function directly. This lets you test the function's HTTP trigger without writing custom client code or managing authentication yourself.

Why this answer

OCI API Gateway can be configured with a route that points to an OCI Function as its backend, exposing the function via a public HTTP URL. This lets you invoke the function directly with a browser or curl without writing custom client code or dealing with OCI's native signed-request authentication.

Exam trap

1Z0-997-26 often tests whether candidates know that OCI Functions natively require signed requests, and that API Gateway is the standard way to expose them as plain HTTP endpoints.

How to eliminate wrong answers

Option B is wrong because an Object Storage pre-authenticated request (PAR) grants time-limited access to a specific object or bucket — it has nothing to do with invoking Functions. Option C is wrong because Cloud Guard is a security posture management service that detects misconfigurations and threats; it does not provide HTTP invocation endpoints for Functions. Option D is wrong because OCI Streaming cursor initialization is about reading from a stream partition, not invoking a Function via HTTP.

Practice this question →
27
MCQhard

You are building a high-throughput event-processing pipeline where multiple consumer instances need to read messages from an OCI Stream concurrently. Each consumer instance must maintain its own independent cursor position and process every message in the stream without interfering with other consumer instances. How should you configure your consumers?

A.Configure each consumer instance to belong to a separate, unique consumer group.
B.Use the OCI Streaming default single-consumer mode with multithreaded polling.
C.Assign all consumer instances to the exact same consumer group and increase the number of partitions.
D.Publish events via OCI Notifications instead, as Streaming does not support consumer groups.
AnswerA

Each OCI Streams consumer group maintains its own committed cursor offset, so separate unique groups give every consumer instance an independent position and a full copy of every message. Sharing a group would partition messages between instances instead.

Why this answer

In OCI Streaming, a consumer group allows multiple consumers to coordinate and share the message processing load, with each message delivered to only one consumer in the group. To have each consumer instance maintain its own independent cursor and process every message, each instance must belong to a separate, unique consumer group. This way, each group gets its own copy of all messages, and each instance can track its own offset independently.

Exam trap

1Z0-997-26 often tests the difference between consumer groups and independent consumers; candidates may think that increasing partitions allows multiple consumers in the same group to each get all messages, but partitions only enable parallelism within a group, not independent consumption.

How to eliminate wrong answers

Option B is wrong because OCI Streaming does not have a 'default single-consumer mode'; consumers must use groups to coordinate, and multithreaded polling within a single consumer does not provide independent cursors for each instance. Option C is wrong because assigning all consumers to the same group would cause them to share the message processing, so each message is processed by only one consumer, not every consumer. Option D is wrong because OCI Streaming does support consumer groups, and OCI Notifications is a different service for pub/sub messaging, not a replacement for stream processing with independent cursors.

Practice this question →
28
Multi-Selectmedium

When designing a container build and deployment pipeline using OCI DevOps and OCI Registry (OCIR), which THREE tasks can be automated within the CI/CD build pipeline stage?

Select 3 answers
A.Push newly built container images securely to OCI Registry (OCIR)
B.Run automated unit tests and code linting scans as part of the build step
C.Automatically provision a brand new OCI Tenancy root compartment
D.Build container images using a build specification file (build_spec.yaml) and Dockerfile
E.Directly modify physical OCI data center HVAC cooling temperatures
AnswersA, B, D

Within the build pipeline stage, OCI DevOps can authenticate to OCIR and push the freshly built image, satisfying the pipeline's artefact publication requirement. This uses the OCIR region endpoint plus an auth token, so the image becomes available for the subsequent deployment stage.

Why this answer

Option A is correct because an OCI DevOps build pipeline can authenticate to OCIR and push newly built container images to it, typically using the DevOps build runner's auth token or instance principal, so the artifact is stored in the registry for later deployment. Option B is correct because the build stage executes commands defined in the build specification, allowing automated unit tests and linting/scanning tools to run as part of the build step before an image is published. Option D is correct because OCI DevOps build pipelines use a build_spec.yaml to define the build steps, and those steps commonly invoke Docker to build container images from a Dockerfile.

Option C is not correct because provisioning a new tenancy root compartment is an identity/tenancy administration task, not a CI/CD build pipeline action. Option E is not correct because physical data center HVAC cooling is facilities infrastructure and is not managed by OCI DevOps pipelines.

Exam trap

1Z0-997-26 often tests the boundaries of what OCI DevOps can automate, tempting candidates to select options that sound like infrastructure automation but are actually outside the CI/CD pipeline scope, such as tenancy provisioning or physical data center operations.

Practice this question →
29
MCQhard

You are troubleshooting a microservice on OKE that is experiencing intermittent 502 Bad Gateway errors when communicating with another internal service. The application uses Kubernetes ClusterIP services for discovery. You suspect DNS resolution failure within the cluster. Which diagnostic tool and approach should you use inside the OKE cluster?

A.Check the OCI VCN internet gateway route table.
B.Deploy a temporary diagnostic container pod (such as netshoot) and test DNS resolution using nslookup against CoreDNS.
C.Review OCI Cloud Guard threat detection policies.
D.Restart the OCI API Gateway service.
AnswerB

A temporary netshoot pod runs inside the cluster, inheriting the same CoreDNS configuration and network namespace as application pods. Querying CoreDNS with nslookup from there isolates whether intermittent 502s stem from in-cluster DNS resolution failures.

Why this answer

Deploying a temporary diagnostic container pod such as netshoot and testing DNS resolution with nslookup against CoreDNS is the correct approach. This allows you to verify whether the cluster's DNS service (CoreDNS) is resolving the internal service name correctly from within a pod, which directly addresses the suspected DNS resolution failure causing 502 errors. It is a standard Kubernetes troubleshooting technique that isolates DNS issues from application or network issues.

Exam trap

1Z0-997-26 often tests whether candidates confuse OCI-level networking (VCN, internet gateway) with Kubernetes-internal DNS troubleshooting, so the trap is selecting VCN or Cloud Guard options instead of an in-cluster diagnostic pod.

How to eliminate wrong answers

Option A is wrong because the OCI VCN internet gateway route table is irrelevant to internal ClusterIP service DNS resolution; ClusterIP services are resolved by CoreDNS inside the cluster, not by VCN routing. Option C is wrong because OCI Cloud Guard threat detection policies are for security posture and threat detection, not for diagnosing DNS resolution inside an OKE cluster. Option D is wrong because restarting the OCI API Gateway service has no bearing on internal Kubernetes DNS resolution between microservices.

Practice this question →
30
MCQmedium

You are configuring an OCI API Gateway deployment to route requests to backend microservices running on OKE. You need to ensure that if a backend microservice takes longer than 3 seconds to respond, the API Gateway cancels the request and returns a 504 Gateway Timeout error to the client. Where should you configure this timeout?

A.In the OCI WAF protection ruleset configuration.
B.In the OCI Load Balancer idle timeout setting associated with the subnet.
C.In the OKE Kubernetes Ingress resource annotations.
D.In the API Gateway deployment specification under the route backend configuration timeout parameter.
AnswerD

The route backend timeout parameter governs how long API Gateway waits for a backend response before aborting. Setting it to 3 seconds makes the gateway cancel the call and return 504, matching the stated requirement precisely.

Why this answer

The API Gateway deployment specification includes a route backend configuration where you can set a timeout parameter that controls how long the gateway waits for a backend response before returning a 504 Gateway Timeout. Configuring the timeout there ensures the gateway cancels the request after 3 seconds as required.

Exam trap

1Z0-997-26 often tests whether candidates confuse load balancer idle timeout with API Gateway backend timeout, so the trap is selecting the Load Balancer setting when the requirement is specifically about the API Gateway's route backend timeout parameter.

How to eliminate wrong answers

Option A is wrong because OCI WAF protection rulesets handle web application firewall filtering (such as SQL injection and XSS rules), not backend response timeouts. Option B is wrong because the Load Balancer idle timeout controls how long an idle connection is kept open, not how long the gateway waits for a backend response, and it is not the API Gateway's timeout mechanism. Option C is wrong because OKE Ingress annotations control the Kubernetes ingress controller's behavior, not the OCI API Gateway's backend timeout, and the question is about API Gateway configuration.

Practice this question →
31
MCQeasy

You are using Fn Project CLI to deploy an OCI Function. Which command is used to build, push, and deploy the function to your application in OCI in a single streamlined step?

A.oci functions function create
B.kubectl apply -f function.yaml
C.docker build and docker push only
D.fn deploy --app <app-name>
AnswerD

The fn deploy command packages the function, pushes the image to the configured registry, and creates or updates the function within the specified application. Supplying --app targets that application, completing build, push and deploy in one streamlined invocation.

Why this answer

The Fn Project CLI command 'fn deploy --app <app-name>' performs the full lifecycle in one step: it builds the function image from the func.yaml, pushes it to the configured Docker registry (such as OCIR), and creates or updates the function and its route in the specified OCI Functions application. This is the canonical streamlined deployment command used with OCI Functions.

Exam trap

1Z0-997-26 often tests whether candidates know the difference between the Fn Project CLI (fn) and the raw OCI CLI (oci), so the trap is selecting an oci functions command that only manages metadata instead of the fn deploy command that builds, pushes, and deploys in one step.

How to eliminate wrong answers

Option A is wrong because 'oci functions function create' is a raw OCI CLI command that only creates the function resource metadata — it does not build or push the container image, so it is not a single streamlined step. Option B is wrong because 'kubectl apply -f function.yaml' is a Kubernetes manifest operation and OCI Functions is not deployed via kubectl manifests. Option C is wrong because 'docker build' and 'docker push' only produce and upload the image; they do not register or deploy the function into an OCI Functions application.

Practice this question →
32
MCQeasy

You need to automate the build, test, and deployment phases of your microservices application whenever developers push code changes to a Git repository on OCI. Which OCI service provides native CI/CD pipelines?

A.OCI Events Service
B.OCI GoldenGate
C.OCI DevOps Service
D.OCI Resource Manager
AnswerC

OCI DevOps Service supplies native build and deployment pipelines, with build runners executing your test and build stages and deployment pipelines releasing artefacts to targets such as OKE or Compute. It integrates directly with OCI Git repositories and external Git providers, satisfying the stem's requirement to trigger automated build, test, and deployment on every code push.

Why this answer

OCI DevOps Service is Oracle Cloud Infrastructure's native CI/CD platform, providing build pipelines, deployment pipelines, and artifact repositories that integrate directly with Git repositories. It automates the build, test, and deployment phases triggered by code pushes, making it the correct choice for native CI/CD on OCI. The other services serve different purposes such as event handling, data replication, or infrastructure-as-code.

Exam trap

The trap is confusing OCI DevOps with other OCI services that sound related (Events, Resource Manager), when only OCI DevOps provides native CI/CD pipeline functionality.

How to eliminate wrong answers

Option A is wrong because OCI Events Service is a publish-subscribe service for reacting to state changes in OCI resources; it can trigger actions but does not itself provide CI/CD pipelines. Option B is wrong because OCI GoldenGate is a data replication and integration service, not a CI/CD tool. Option D is wrong because OCI Resource Manager is a Terraform-based infrastructure-as-code service for provisioning resources, not for building and deploying application code.

Practice this question →
33
MCQmedium

Your OKE cluster has autoscaling enabled using the Kubernetes Cluster Autoscaler. However, during peak hours, new pods remain in 'Pending' state for 15 minutes before the cluster autoscaler provisions new worker nodes. How can you reduce this provisioning delay?

A.Deploy Kubernetes over-provisioning pods (pause pods) with lower priority to keep spare node capacity ready instantly.
B.Convert all worker nodes from virtual machines to bare metal shapes.
C.Increase the OCI Load Balancer bandwidth shape to maximum.
D.Disable OCI IAM token caching on worker nodes.
AnswerA

Over-provisioning pause pods with low priority reserve idle node capacity, so pending workload pods pre-empt them immediately rather than waiting for the Cluster Autoscaler to react. This directly removes the 15-minute scale-up delay during peak hours, since capacity already exists and no node provisioning cycle is triggered.

Why this answer

Over-provisioning pods (low-priority pause pods) reserve spare capacity on existing nodes so that when a real workload pod is scheduled, it can immediately preempt the pause pod and start running without waiting for the Cluster Autoscaler to provision a new node. This eliminates the 15-minute node provisioning delay during peak hours.

Exam trap

1Z0-997-26 often tests whether candidates understand that autoscaler latency is a scheduling problem solvable with priority-based over-provisioning, not a hardware or networking problem, tricking them into choosing bare metal or load balancer options.

How to eliminate wrong answers

Option B is wrong because bare metal shapes still require provisioning time and do not inherently reduce the autoscaler's node startup latency; they may even be slower to provision. Option C is wrong because load balancer bandwidth affects traffic throughput, not pod scheduling or node provisioning delays. Option D is wrong because IAM token caching on worker nodes is unrelated to the time it takes the Cluster Autoscaler to detect pending pods and provision new nodes.

Practice this question →
34
Multi-Selecthard

Which TWO architectural best practices should you follow when designing cloud-native microservices on Oracle Container Engine for Kubernetes (OKE) to ensure high availability and resilience? (Choose two.)

Select 2 answers
A.Deploy all microservices into a single flat Kubernetes namespace to maximize intra-cluster communication speed.
B.Store all application state and user sessions locally on the ephemeral container root filesystem.
C.Distribute OKE worker node pools across multiple Fault Domains or Availability Domains.
D.Use NodePorts for all external microservice access directly bypassing the OCI Load Balancer.
E.Configure Kubernetes Pod Disruption Budgets (PDBs) to control minimum available pods during maintenance or scaling events.
AnswersC, E

Spreading worker node pools across multiple Fault Domains or Availability Domains ensures that a single domain failure cannot take down all nodes hosting the microservices, satisfying the high-availability and resilience requirement by removing a shared failure domain.

Why this answer

Option C is correct because spreading OKE worker node pools across multiple Fault Domains or Availability Domains ensures that a failure in one physical domain does not take down the entire cluster, which is a fundamental high-availability practice for cloud-native microservices. Option E is correct because Kubernetes Pod Disruption Budgets (PDBs) define the minimum number of pods that must remain available during voluntary disruptions such as node maintenance, upgrades, or scaling, directly supporting resilience and availability guarantees. Option A is not recommended because a single flat namespace does not improve communication speed and reduces isolation, making it harder to apply network policies, resource quotas, and RBAC for microservices.

Option B is incorrect because storing state or sessions on the ephemeral container root filesystem means data is lost when the pod restarts or is rescheduled, breaking resilience; state should be externalized to a database or persistent volume. Option D is incorrect because exposing all microservices via NodePorts bypasses the OCI Load Balancer, lacks advanced traffic management, TLS termination, and health checks, and is not a best practice for production high availability.

Exam trap

1Z0-997-26 often tests HA design patterns, and candidates pick options that sound efficient (single namespace, NodePorts) but actually reduce resilience or bypass managed load-balancing features.

Practice this question →
35
Multi-Selecthard

You are migrating a monolithic application to microservices on OKE and implementing resilient design patterns. Which THREE resiliency patterns should you implement to handle transient failures gracefully?

Select 3 answers
A.Circuit Breaker pattern to prevent cascading failures when downstream services are struggling
B.Bulkhead pattern to isolate resource pools (e.g., thread pools) so one failing service doesn't starve others
C.Single large monolithic database instance shared by all microservices without connection pooling
D.Retries with Exponential Backoff and Jitter for transient network or service errors
E.Disabling all health checks and liveness probes to prevent container restarts
AnswersA, B, D

The Circuit Breaker pattern trips after repeated downstream failures, short-circuiting further calls so struggling services are not overwhelmed and failures do not cascade. This satisfies the requirement to handle transient failures gracefully across microservices on OKE.

Why this answer

Option A (Circuit Breaker) is correct because it detects repeated failures to a downstream service and trips open, failing fast instead of letting threads pile up waiting on a struggling dependency, which prevents cascading failures across the microservice mesh. Option B (Bulkhead) is correct because it partitions resources such as thread pools or connection pools per dependency, so a single slow or failing service cannot exhaust all shared resources and starve healthy services. Option D (Retries with Exponential Backoff and Jitter) is correct because transient network blips, brief DNS hiccups, or momentary 503s are often resolved by retrying, and exponential backoff with jitter avoids synchronized retry storms that would otherwise overwhelm the recovering service.

Option C is not a resiliency pattern but an anti-pattern: a single shared monolithic database without connection pooling creates a shared point of contention and failure, coupling all microservices and amplifying outages. Option E is wrong because disabling health checks and liveness probes removes Kubernetes' ability to detect and restart unhealthy containers, degrading rather than improving resilience.

Exam trap

1Z0-997-26 often tests the confusion between resiliency patterns and anti-patterns, such as shared monolithic databases or disabling health checks, which candidates might mistakenly select as valid.

Practice this question →
36
MCQmedium

Your OKE cluster is deployed in a private subnet with no direct outbound internet access. However, your pods need to pull container images from OCI Registry (OCIR). How should you enable this secure image pull without exposing worker nodes to the public internet?

A.Install an external Squid proxy on an on-premises server connected via IPsec VPN.
B.Set up a NAT Gateway and forward all traffic to the internet.
C.Attach a Public IP address to every worker node in the OKE cluster.
D.Configure an OCI Service Gateway in your VCN and add a route rule for OCI Services to the private subnet's route table.
AnswerD

A Service Gateway provides private access to OCI services, including OCIR, without traversing the internet. Adding a route rule for OCI Services to the private subnet's route table directs image-pull traffic through this gateway, satisfying the no-outbound-internet constraint while keeping worker nodes unexposed.

Why this answer

An OCI Service Gateway provides private access from a VCN to OCI public services like OCIR without traversing the internet. By adding a route rule in the private subnet's route table pointing OCI Services traffic to the Service Gateway, pods can pull images securely while worker nodes remain isolated from the public internet.

Exam trap

1Z0-997-26 often tests the distinction between NAT Gateway (internet-bound) and Service Gateway (OCI-services-only), causing candidates to choose NAT when the requirement is private access to OCI services like OCIR.

How to eliminate wrong answers

Option A is wrong because an on-premises Squid proxy over IPsec VPN adds unnecessary complexity, latency, and an external dependency — it is not the OCI-native secure solution. Option B is wrong because a NAT Gateway routes traffic to the public internet, which violates the requirement of not exposing worker nodes and is unnecessary for OCI-internal service access. Option C is wrong because attaching public IPs to worker nodes directly exposes them to the internet, contradicting the security requirement.

Practice this question →
37
MCQeasy

You have deployed an API on OCI API Gateway and want to protect it from common web attacks such as SQL injection, cross-site scripting (XSS), and bad bots. Which OCI service should you integrate with API Gateway?

A.OCI Vulnerability Scanning Service
B.OCI Web Application Firewall (WAF)
C.OCI Bastion Service
D.OCI Cloud Guard
AnswerB

OCI Web Application Firewall inspects inbound HTTP traffic at layer 7, applying managed rule sets that detect and block SQL injection, cross-site scripting and bot signatures before requests reach the gateway. Integrating it with API Gateway satisfies the stem's requirement to defend the deployed API against those common web attacks.

Why this answer

OCI Web Application Firewall (WAF) is designed to protect web applications and APIs from common web attacks like SQL injection, XSS, and bad bots by inspecting HTTP/HTTPS traffic and applying rule-based filtering. It integrates directly with OCI API Gateway, allowing you to attach a WAF policy to the gateway to enforce security rules at the edge. This integration provides layer 7 protection without modifying the backend API.

Exam trap

1Z0-997-26 often tests the distinction between security services that provide preventive traffic filtering (WAF) versus those that provide posture management (Cloud Guard) or vulnerability detection (Vulnerability Scanning Service), causing candidates to confuse their primary functions.

How to eliminate wrong answers

Option A is wrong because OCI Vulnerability Scanning Service identifies vulnerabilities in compute instances and containers, not in web traffic, and does not provide runtime protection against SQL injection or XSS. Option C is wrong because OCI Bastion Service provides secure SSH/RDP access to private subnets, not web application firewall capabilities. Option D is wrong because OCI Cloud Guard is a security posture management service that detects misconfigurations and threats across OCI resources, but it does not inspect or filter HTTP traffic to protect APIs from web attacks.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Cloud Native Architecture questions.

Start 20-question session