PORTWORX-ENTERPRISE-PROFESSIONAL Practice Questions

The Portworx OCI monitor (px-oci-mon) is a critical component that runs as a container within the Portworx DaemonSet on each node. Its primary function is to act as a watchdog for the node's health from a storage perspective. It continuously monitors the state of the underlying OCI-compliant container runtime (like containerd or Docker) and the main Portworx service. If it detects that either of these essential services has become unresponsive, it will take corrective action, such as restarting the Portworx container, to restore the node's functionality and ensure the stability of the Portworx storage cluster.

A. To facilitate the installation of Portworx: Installation is handled by the Portworx Operator or by applying Kubernetes spec files, not by the OCI monitor, which operates post-installation.

C. To manage Kubernetes network policies: Network policy enforcement is the responsibility of a Container Network Interface (CNI) plugin (e.g., Calico, Weave), not the Portworx storage layer.

1. Portworx Enterprise Documentation: In the section describing the components

the OCI monitor is explicitly defined. "The Portworx DaemonSet... includes the following containers: ... px-oci-mon: Monitors the OCI container runtime and restarts Portworx if it becomes unresponsive."

Source: Portworx Docs

Reference > Components > Portworx components on Kubernetes.

2. Portworx Enterprise Documentation: The troubleshooting guide for unresponsive nodes implicitly details the role of health monitoring components like the OCI monitor. It explains that if the Portworx daemon on a node becomes unhealthy

the monitor attempts to recover it.

Source: Portworx Docs

Operate and Maintain > Troubleshoot Portworx > Troubleshoot nodes > Node is down.

To expose Portworx metrics to an externally managed Prometheus instance, the administrator must modify the StorageCluster custom resource. The correct method is to set the exportMetrics flag to true under the spec.monitoring.prometheus path. This declarative approach instructs the Portworx Operator to create the necessary ServiceMonitor or PodMonitor resources that the external Prometheus Operator can discover, allowing it to scrape metrics from Portworx pods without deploying the Portworx-internal Prometheus stack.

B. The exportMetrics field is incorrectly placed. According to the StorageCluster CRD schema, it must be nested within the prometheus object, not directly under monitoring.

C. Using pxctl is an imperative command. The standard, declarative, and idempotent method for managing cluster-wide configuration in an operator-managed Portworx installation is by modifying the StorageCluster object.

1. Portworx Enterprise Documentation

"Monitor Portworx with Prometheus": This official document details the configuration for monitoring. In the section "Using an existing Prometheus Operator

" it explicitly states: "If you want to use an existing Prometheus Operator to monitor Portworx

you must enable the exportMetrics flag in the StorageCluster spec." It then provides the exact YAML structure shown in option A.

Source: Portworx by Pure Storage Official Documentation. Navigate to the Monitor and Troubleshoot -> Monitor Portworx with Prometheus -> Using an existing Prometheus Operator section.

2. Portworx Enterprise Documentation

"Portworx Operator Spec / CRD Reference": The reference for the StorageCluster Custom Resource Definition confirms the object hierarchy. The monitoring spec contains a prometheus object

which in turn contains the exportMetrics boolean field. This schema validates that spec.monitoring.prometheus.exportMetrics is the correct path.

Source: Portworx by Pure Storage Official Documentation. Navigate to the Reference -> Portworx Operator on Kubernetes -> Operator Spec / CRD Reference section and inspect the StorageCluster spec.

The pxctl credentials create command is the designated utility within the Portworx command-line interface for registering cloud provider credentials. This command allows an administrator to securely store access keys and other necessary authentication details for various cloud services, such as AWS S3, Azure Blob Storage, or Google Cloud Storage. These stored credentials are then used by Portworx for features that interact with the cloud, most notably for creating cloud snapshots and backing up volumes to an object store. The command requires specifying the provider and the relevant authentication parameters.

A. pxctl service credentials create: This is not a valid Portworx command. The pxctl service subcommand is used for managing internal Portworx services (e.g., pxctl service diags), not for managing external cloud credentials.

B. pxctl credentials generate: The generate subcommand is not a valid action for pxctl credentials. The correct verb for establishing a new credential entry is create, which involves providing pre-existing keys from a cloud provider.

1. Portworx Enterprise Documentation

"Manage cloud credentials": This official document explicitly details the procedure for managing cloud credentials. Under the "Create cloud credentials" section

it states

"To create cloud credentials

you must use the pxctl credentials create command..." and provides syntax examples for AWS

Azure

and GCP.

Source: Portworx by Pure Storage

Official Documentation.

Section: Operate and Maintain on Kubernetes -> Storage operations -> Manage cloud credentials -> Create cloud credentials.

2. Portworx Enterprise Documentation

"pxctl reference": The command-line reference guide lists all valid commands and subcommands. It confirms that create is a valid subcommand for pxctl credentials

while generate is not. It also shows that credentials is not a subcommand of pxctl service.

Source: Portworx by Pure Storage

Official Documentation.

Section: Reference -> CLI Reference -> pxctl -> pxctl credentials.

The VolumeSnapshot is a namespaced Kubernetes API resource that users create to initiate a snapshot of a PersistentVolumeClaim (PVC). The VolumeSnapshot object's specification (spec) contains a source field that explicitly references the parent volume by its persistentVolumeClaimName. Once the underlying storage provider, such as Portworx, successfully creates the snapshot, the status field of the VolumeSnapshot object is updated. This status includes a reference (boundVolumeSnapshotContentName) to the VolumeSnapshotContent object, which holds the unique snapshot identifier (snapshotHandle) from the storage system. Therefore, the VolumeSnapshot resource provides direct visibility to the parent volume (PVC) and an indirect link to the snapshot ID.

B. PersistentVolumeClaim: A PersistentVolumeClaim (PVC) is a request for storage. While it is the source for a snapshot, the PVC object itself does not contain any information or references to snapshots that have been created from it.

C. VolumeSnapshotData: VolumeSnapshotData is a deprecated API object from the pre-CSI snapshot implementation. The modern equivalent is VolumeSnapshotContent, which contains the snapshot ID but references the source PersistentVolume, not the user-facing PersistentVolumeClaim.

1. Kubernetes Official Documentation

"Volume Snapshots": The documentation details the VolumeSnapshot object. The sample YAML manifest for a VolumeSnapshot clearly shows the spec.source.persistentVolumeClaimName field

which identifies the parent volume. The description of the object's lifecycle explains how its status field links to the VolumeSnapshotContent object.

Source: Kubernetes Documentation > Concepts > Storage > Volume Snapshots.

Section: "VolumeSnapshot" and "VolumeSnapshotContent".

2. Portworx Official Documentation

"CSI Snapshots": This document provides a step-by-step guide for creating CSI-based snapshots with Portworx. The examples explicitly show the creation of a VolumeSnapshot resource that references a source PVC. This confirms that the VolumeSnapshot object is the user-facing resource for managing the relationship between a parent volume and its snapshot.

Source: Portworx Enterprise Documentation > Portworx on Kubernetes > Storage operations > Snapshots > Create and use snapshots with Kubernetes > CSI Snapshots.

Section: "Create a CSI snapshot".

A Portworx StorageClass in Kubernetes is a fundamental component for enabling dynamic volume provisioning. It allows administrators to define different tiers or profiles of storage, specifying parameters such as replication factor (repl), I/O profile (ioprofile), and encryption. When a user submits a PersistentVolumeClaim (PVC) that references a Portworx StorageClass, the Portworx provisioner automatically creates a corresponding PersistentVolume (PV) that matches the defined specifications, without requiring manual intervention. This process is the essence of automated storage provisioning.

A. Automated monitoring: Monitoring is handled by separate components like Prometheus or Portworx Central, not by the StorageClass object, which defines storage policies.

C. Automated backups: While snapshot policies can be linked to a StorageClass, the automation of backup schedules and lifecycle management is handled by Portworx Backup (PX-Backup), not the StorageClass itself.

1. Portworx Enterprise Documentation

"Dynamic Provisioning": "Portworx can dynamically provision volumes for your applications. Using Kubernetes StorageClasses

you can define different storage profiles for your applications. When your users request a volume

they can select one of these profiles without having to worry about the underlying storage."

Source: Portworx by Pure Storage Official Documentation. Section: Storage Operations -> Provisioning on Kubernetes -> Dynamic Provisioning.

2. Kubernetes Official Documentation

"Storage Classes": "A StorageClass provides a way for administrators to describe the 'classes' of storage they offer... StorageClass objects are also a mechanism that allow administrators to specify a default provisioner and parameters for when a PVC does not request any specific class."

Source: Kubernetes Documentation. Section: Concepts -> Storage -> Storage Classes.

3. Portworx Enterprise Documentation

"Create a StorageClass": "A StorageClass provides a way for administrators to describe the 'classes' of storage they offer. Different classes might map to quality-of-service levels

or to backup policies

or to arbitrary policies determined by the cluster administrators. When a user creates a persistent volume claim

they can specify a storage class

which will then be used to dynamically provision a volume."

Source: Portworx by Pure Storage Official Documentation. Section: Install and Configure -> Install Portworx -> Install Portworx on Kubernetes -> Create a StorageClass.

To deterministically control which nodes host the internal Portworx Key-Value Database (KVDB), an administrator must define node selection criteria within the StorageCluster custom resource specification. The spec.kvdb section is designed for this purpose. By using a selector, such as nodeAffinity or a nodeSelector, the Portworx Operator can be instructed to schedule the KVDB pods exclusively on the specified nodes. While the exact syntax in the option may be a simplification, the principle of modifying the StorageCluster spec with a node selector is the correct and necessary step to enforce this placement.

A: This is incorrect. Portworx provides granular control over the placement of its components, including the internal KVDB, through the StorageCluster specification.

C: Simply labeling nodes is insufficient. While labeling is a valid strategy, the StorageCluster spec must also be explicitly configured with a selector that targets those labels. The act of labeling alone does not influence KVDB placement.

1. Portworx Enterprise Documentation

"Specify nodes for internal kvdb": This official document details the methods for controlling KVDB placement. It explicitly shows how to use nodeAffinity within the spec.kvdb section to select nodes based on their hostnames (kubernetes.io/hostname)

which is the technically precise implementation of the goal described in the question. It also shows the alternative method of using a selector to target node labels.

Reference Location: Portworx Docs -> Install and Configure -> Install Portworx -> Install on Kubernetes -> Using the Operator -> Create the StorageCluster -> Specify nodes for internal kvdb.

2. Portworx Enterprise Documentation

"CustomResourceDefinition concepts": This document outlines the structure of the StorageCluster CRD. The kvdb field is shown to contain properties like nodeAffinity and selector

confirming that the StorageCluster object is the correct place to define KVDB placement rules.

Reference Location: Portworx Docs -> Reference -> Kubernetes -> CustomResourceDefinition concepts -> StorageCluster -> KvdbSpec.

The StorageCluster is the primary Custom Resource Definition (CRD) used by the Portworx Operator to deploy and manage a Portworx cluster. This object's specification (spec) contains all the essential parameters for the installation, including the Portworx image version, storage device configurations, network interfaces, environment variables, and other cluster-wide settings. Administrators define the desired state of the Portworx installation within this single CRD object, and the Operator works to reconcile the cluster to match this state.

A. VolumeSnapshot: This is a standard Kubernetes API resource for creating point-in-time snapshots of persistent volumes. It is an operational object, not one used for configuring the Portworx cluster installation.

C. ServiceAccount: This is a standard Kubernetes object that provides an identity for processes running in pods. While Portworx uses ServiceAccounts for permissions, it is not the CRD for defining installation parameters.

1. Portworx Enterprise Documentation

"Portworx Spec CRD": "The StorageCluster custom resource is the main custom resource that you will interact with to deploy and manage the Portworx cluster. The Portworx Operator will watch for this custom resource and will deploy/update/delete the Portworx cluster based on the spec." (Reference found under the "Reference -> Portworx CRDs -> Portworx Spec CRD" section).

2. Portworx Enterprise Documentation

"Generate the Portworx spec": "The Portworx Operator deploys Portworx on your cluster using a spec from a StorageCluster object. You can generate this spec using the Portworx spec generator page in Portworx Central." (Reference found under the "Install and Configure -> Portworx on Kubernetes -> Install with the Operator -> On-premises" section).

3. Portworx Enterprise Documentation

"CRD-based configuration": This section details the various fields within the StorageCluster spec

such as image

storage

network

and env

confirming it is the central point for installation configuration. (Reference found under "Operate and Maintain -> Configuration -> CRD-based configuration").

Portworx defragmentation is an I/O-intensive operation designed to reclaim space and improve the performance of volumes. Because of its resource-intensive nature, it can impact the performance of active applications. By setting a defragmentation schedule, administrators can automate this task to run during periods of low cluster workload, such as nights or weekends. This ensures that the performance benefits of defragmentation are achieved without negatively affecting production services during peak hours.

B. To back up data to the cloud.

This is incorrect. Portworx uses separate features like CloudSnaps or PX-Backup for backing up data to cloud object stores, which is a distinct process from defragmentation.

C. To monitor the health of the storage cluster.

This is incorrect. Cluster health is monitored using tools like pxctl status, the Portworx monitoring stack (Prometheus/Grafana), or other observability platforms, not by scheduling defragmentation.

1. Portworx Enterprise Documentation

"Defragmentation": "Defragmentation is an I/O intensive operation

so you should run it during a maintenance window or when your cluster is not under a heavy I/O load. You can schedule defragmentation to run at a specific time on a recurring basis to avoid impacting your applications." (This section explicitly states the purpose is to improve performance and the reason for scheduling is to run during low workload periods).

2. Portworx Enterprise Documentation

"pxctl volume commands"

pxctl volume defrag schedule create: The documentation for this command details how to "Create a recurring defragmentation schedule for a volume

" providing options for daily

weekly

and monthly schedules at specific times

reinforcing the concept of running the operation during planned

low-impact windows.

To create a Portworx volume that is both encrypted and has two replicas using a Kubernetes StorageClass, the correct parameters must be specified. The repl: "2" parameter correctly sets the volume's replication factor to two. The secure: "true" parameter is the specific Portworx directive used within a StorageClass to enable per-volume encryption. This combination directly fulfills the administrator's requirements for creating volumes with these characteristics.

A. The parameter encrypted: "true" is not a valid Portworx StorageClass parameter. The correct parameter to enable volume encryption is secure: "true".

B. The parameter sharedv4: "true" is used to provision a shared, multi-writer (RWX) volume and is not related to enabling volume encryption.

1. Portworx Enterprise Documentation

"Create Portworx volumes with Kubernetes": This official document provides a table of "Commonly used parameters" for StorageClasses. It explicitly lists:

secure: "Set to true to create an encrypted volume. Default is false."

repl: "Replication factor for the volume

for example

repl: "2". The default is 1."

This directly supports the use of secure: "true" and repl: "2" as seen in option C.

2. Portworx Enterprise Documentation

"Volume Encryption with Kubernetes": This section details the process of creating encrypted volumes. It provides a sample StorageClass YAML that uses secure: "true" to enable encryption

reinforcing that this is the correct parameter. The document states

"To create an encrypted volume

you must create a StorageClass with the parameter secure set to true."

3. Portworx Enterprise Documentation

"Shared Volumes": This page explains the creation of ReadWriteMany (RWX) volumes and shows that the sharedv4: "true" parameter is used for this purpose

confirming it is unrelated to encryption.

To prevent Portworx from being installed on a specific node, an administrator must apply the px/enabled=false label to that Kubernetes node. The Portworx Operator and DaemonSet are configured with a node affinity rule that actively avoids scheduling Portworx pods on any node carrying this specific label. This is the designated method for explicitly excluding nodes from a Portworx installation, ensuring that the Portworx components are never deployed to them.

A. px/service=stop: This label is used to stop the Portworx service on a node where it is already installed and running, typically for maintenance, not to prevent the initial installation.

C. px/storage-node=false: This label designates a node as "storageless." Portworx is still installed on such nodes, but they do not contribute storage to the cluster; they only provide volume access.

1. Portworx Enterprise Documentation

"Exclude nodes from Portworx installation": "To prevent Portworx from installing on a specific node

apply the px/enabled=false label to that node. The Portworx DaemonSet uses a node selector to avoid nodes with this label." (Found under Install and Configure -> Install Portworx -> Install on Kubernetes -> On-premises -> Operator -> Customize the Operator install).

2. Portworx Enterprise Documentation

"Storageless nodes": "You can configure Portworx to run on storageless nodes by applying the px/storage-node=false label to them. Portworx still runs on these nodes

but they do not contribute any storage to the storage cluster." (Found under Storage Management -> Storageless nodes).

3. Portworx Enterprise Documentation

"Enter maintenance mode": "To place a node in maintenance mode

enter the following kubectl label command... kubectl label node px/service=stop --overwrite" (Found under Operate and Maintain -> Maintenance -> Decommission a node -> Enter maintenance mode).