Initial commit: OpenShift expert EEM knowledge base for HuggingFace

3,820 justified beliefs covering the operator-driven platform model,
networking, virtualization, security, edge deployments, and 50+
OpenShift subsystems. Includes 904 exploration entries as provenance.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.gitignore

@@ -0,0 +1,3 @@
+reasons.db
+reasons.db-shm
+reasons.db-wal

CLAUDE.md

@@ -0,0 +1,41 @@
+# CLAUDE.md — OpenShift Expert
+
+Expert agent for explaining OpenShift Container Platform behavior, architecture, and operational patterns. Knowledge is stored in `reasons.db` — a justified belief network with retraction cascades, not a flat knowledge base.
+
+## Mission
+
+Help humans and LLM agents understand OpenShift platform architecture, operator lifecycle, networking, security, virtualization, and edge deployment patterns. Answers should be grounded in the belief network (`reasons.db`), not parametric knowledge. Use `reasons search`, `reasons explain`, and `reasons show` to find and cite beliefs before answering.
+
+## How to Answer Questions
+
+1. `reasons search "relevant terms"` to find beliefs
+2. `reasons explain NODE` to trace justification chains
+3. Synthesize an answer grounded in the beliefs found
+4. Cite node IDs so the questioner can audit the chain
+
+## What This Expert Knows
+
+- Platform model: operator-driven immutable infrastructure, RHCOS, MCO
+- Hosted Control Planes (HCP): multi-tenancy, topology variants
+- Networking: OVN-Kubernetes, Multus, SR-IOV, IPsec, egress firewalls, network policies
+- Virtualization: OpenShift Virtualization (CNV/OCP-Virt), live migration, VM management
+- Operators & OLM: Operator Lifecycle Manager, OperatorHub, File-Based Catalogs
+- Security: SCCs, RBAC, OAuth, webhook admission, network policies
+- Builds & CI/CD: S2I, Shipwright, Jenkins, GitOps, image streams
+- Edge: ZTP, TALM, Single Node OpenShift (SNO), vDU workloads
+- Observability: monitoring, logging, Network Observability (NetObserv)
+- Storage: CSI drivers, dynamic provisioning, OADP backup
+- Installation: IPI/UPI, platform-specific (AWS, Nutanix, IBM Cloud, bare metal, Power)
+- Node management: MachineConfig, autoscaling, health checks, tuned profiles
+
+## Skills Available
+
+```bash
+reasons search QUERY              # Find beliefs by keyword
+reasons show NODE                 # Full details + dependents
+reasons explain NODE              # Trace justification chain
+reasons list                      # All nodes with status
+reasons list --premises           # Foundation beliefs
+reasons list --has-dependents     # Load-bearing beliefs
+reasons export-markdown -o beliefs.md  # Export readable snapshot
+```

README.md

@@ -0,0 +1,163 @@
+---
+schema_version: "1.0"
+type: eem
+project_name: openshift-expert
+domain:
+  - openshift
+  - kubernetes
+  - container-platform
+  - cloud-infrastructure
+license: mit
+base_network: null
+source_repos: []
+beliefs_total: 3820
+beliefs_in: 3820
+beliefs_out: 0
+premises: 3670
+derived: 150
+nogoods: 0
+generator: ftl-reasons/0.41.0
+---
+
+# OpenShift Expert
+
+Expert knowledge base for **OpenShift Container Platform** architecture, operations, and deployment patterns. Contains 3,820 justified beliefs covering the operator-driven platform model, networking, virtualization, security, edge deployments, and 50+ subsystems.
+
+## What is this?
+
+This is an **External Epistemic Memory** (EEM) — a model-agnostic knowledge base that any LLM can use via the `reasons` CLI or tool calling. Unlike a LoRA or fine-tune, this knowledge is not baked into model weights. It is external, inspectable, correctable, and works with any model.
+
+## Stats
+
+| Metric | Value |
+|--------|-------|
+| Total beliefs | 3,820 |
+| Status | 3,820 IN / 0 OUT |
+| Premises (observations) | 3,670 |
+| Derived (justified conclusions) | 150 |
+| Nogoods (contradictions) | 0 |
+| Retraction rate | 0% |
+| Max derivation depth | 7 |
+
+## Top Topics
+
+| Topic | Beliefs |
+|-------|---------|
+| ocp | 560 |
+| default | 312 |
+| api | 224 |
+| cluster | 192 |
+| operator | 192 |
+| openshift | 159 |
+| namespace | 124 |
+| node | 120 |
+| hcp | 110 |
+| config | 108 |
+| network | 99 |
+| image | 91 |
+| virt | 91 |
+| install | 85 |
+| supported | 74 |
+| policy | 72 |
+
+## Domain Coverage
+
+- **OCP Core Platform**: operator-driven immutable model, cluster versioning, install-time constraints, platform topology variants (511 beliefs)
+- **Hosted Control Planes (HCP)**: multi-tenant control planes, NodePool management, hosted cluster lifecycle (107 beliefs)
+- **CLI & API**: `oc` commands, API resources, resource management, debugging (63 beliefs)
+- **OpenShift Virtualization (CNV)**: VM lifecycle, live migration, virtual networking, storage for VMs (82 beliefs)
+- **Networking — OVN-Kubernetes**: default CNI, pod networking, service routing, hybrid overlay (27 beliefs)
+- **Networking — Policy & Firewalls**: network policies, egress firewalls, admin network policies, user-defined networks (40 beliefs)
+- **Networking — SR-IOV**: hardware-accelerated networking, VF management, node policies (28 beliefs)
+- **Networking — Ingress & Routes**: HAProxy ingress controller, route configuration, TLS termination (34 beliefs)
+- **Networking — IPsec & Encryption**: IPsec tunnel configuration, node-to-node encryption (12 beliefs)
+- **Operators & OLM**: Operator Lifecycle Manager, OperatorHub, File-Based Catalogs, bundle management (87 beliefs)
+- **Etcd**: cluster database, backup/restore, performance tuning, defragmentation (37 beliefs)
+- **Security — SCCs & RBAC**: Security Context Constraints, role-based access control, project isolation (28 beliefs)
+- **Security — OAuth & Authentication**: OAuth server, identity providers, token management (24 beliefs)
+- **Security — Webhook Admission**: validating/mutating webhooks, enforcement model (16 beliefs)
+- **Builds & Images**: S2I builds, Shipwright, image streams, image registry, samples operator (70 beliefs)
+- **CI/CD & GitOps**: Jenkins pipelines, OpenShift GitOps (ArgoCD), deployment strategies (36 beliefs)
+- **Edge — ZTP & SNO**: Zero Touch Provisioning, Single Node OpenShift, TALM upgrades, vDU workloads (53 beliefs)
+- **Node Management**: MachineConfig Operator, machine sets, autoscaling, health checks, tuned profiles (57 beliefs)
+- **Observability**: monitoring stack, logging, Network Observability (NetObserv), flow collection (54 beliefs)
+- **Console**: web console, console plugins, developer/admin perspectives (43 beliefs)
+- **Storage**: CSI drivers, dynamic provisioning, persistent volumes (10 beliefs)
+- **Backup & DR**: OADP, etcd backup, cluster restore (13 beliefs)
+- **Platform Variants**: Nutanix, IBM Cloud, IBM Power, bare metal, ROSA, OCI (101 beliefs)
+- **RHCOS & Node OS**: Red Hat CoreOS, immutable OS, ignition, ostree updates (13 beliefs)
+- **Additional topics**: NMState, MetalLB, templates, jobs, probes, ConfigMaps, HPA, PDB, scheduler, RHOSO, RHOAI (remaining beliefs)
+
+## How to Use
+
+### Import into a reasons database
+
+```bash
+reasons init
+reasons import-json network.json
+```
+
+### Query beliefs
+
+```bash
+reasons search "operator lifecycle"
+reasons explain operator-driven-immutable-platform-model
+reasons show install-time-irreversible-constraints
+```
+
+### Use as an MCP tool or CLI
+
+Any LLM agent that can call `reasons search`, `reasons show`, and `reasons explain` can use this knowledge base. The agent does not need to be told it is an expert — the knowledge base speaks for itself.
+
+## Key Beliefs
+
+| Node | Summary |
+|------|---------|
+| `operator-driven-immutable-platform-model` | The entire OpenShift platform operates through an operator-driven model with immutable infrastructure |
+| `install-time-irreversible-constraints` | Multiple cluster-defining decisions are permanently locked at install time and cannot be changed |
+| `observability-follows-platform-enablement-pattern` | OpenShift observability is a specific instance of the platform-wide multi-component enablement pattern |
+| `edge-fleet-management-pipeline` | Edge cluster lifecycle follows a managed pipeline: ZTP + GitOps provisions, TALM orchestrates upgrades |
+| `multi-cni-network-architecture` | OpenShift uses a layered CNI architecture: OVN-Kubernetes primary, Multus for additional networks |
+| `webhook-admission-enforcement-model` | Webhook admission follows a constrained enforcement model with TLS requirements |
+| `node-config-immutable-delivery-pipeline` | Node configuration follows an immutable delivery pipeline via MachineConfig Operator |
+| `complete-software-delivery-from-build-to-console` | OpenShift provides a unified software delivery model covering application and operator lifecycles |
+| `platform-model-with-topology-variants` | Single operator-driven platform model recognizing two sanctioned topology variants |
+| `consoleplugin-compat-level-1` | ConsolePlugin has Compatibility Level 1: stable for at least 12 months or 3 minor releases |
+
+## Sources
+
+Built from exploration of OpenShift Container Platform documentation, API references, and operational experience across networking, virtualization, security, edge, and platform management subsystems.
+
+## Files
+
+| File | Description |
+|------|-------------|
+| `network.json` | Full belief network (machine-readable, portable) |
+| `reasons.db` | SQLite database (gitignored, regenerate with `reasons import-json network.json`) |
+| `CLAUDE.md` | Agent instructions for using this knowledge base |
+| `entries/` | 904 exploration entries — raw observations behind the premises |
+
+## Quality
+
+- All 3,820 beliefs are IN (none retracted)
+- 3,670 premises grounded in direct observations of OpenShift behavior and documentation
+- 150 derived beliefs justified from premises via SL justifications
+- 0 nogoods — no contradictions detected
+- Max derivation depth of 7, indicating multi-step reasoning chains
+- Built and reviewed using ftl-reasons derive and review-beliefs pipeline
+
+## Limitations
+
+- Focused on OpenShift Container Platform as of mid-2026
+- OpenShift evolves across minor releases; some beliefs may become stale
+- Heavier coverage of networking, virtualization, and operators than storage or serverless
+- Platform variant coverage (Nutanix, IBM, bare metal) varies in depth
+- No ATMS or assumption-based beliefs (single-context TMS only)
+
+## Authors
+
+- Ben Thomasson ([@benthomasson](https://github.com/benthomasson))
+
+## License
+
+mit

entries/2026/03/05/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md

@@ -0,0 +1,35 @@
+---
+source_url: https://docs.redhat.com/documentation/red_hat_openshift_cluster_observability_operator/1-latest/html/about_red_hat_openshift_cluster_observability_operator/index
+source: sources/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:11
+
+
+
+## Overview
+The Red Hat OpenShift Cluster Observability Operator (COO) is an operator that provides observability features for OpenShift clusters. This page serves as the introductory landing page for the COO documentation (version 1-latest), covering its purpose and linking to release notes and support information.
+
+## Key Concepts
+- **Cluster Observability Operator (COO)** is a dedicated operator for cluster-level observability in OpenShift
+- It is a separate product/operator from the built-in monitoring stack (which uses the Cluster Monitoring Operator)
+- Versioned as "1-latest," indicating it is an independently released component outside the core OpenShift release cycle
+- Maintained by Red Hat as an officially supported operator
+
+## Commands and Syntax
+No commands or configuration syntax are provided on this introductory page.
+
+## Relationships
+- **Cluster Monitoring Operator (CMO)**: The built-in OpenShift monitoring stack; COO is a complementary/alternative observability solution
+- **OperatorHub / OLM**: COO is installed via the Operator Lifecycle Manager as an optional operator
+- **Observability stack components**: COO likely integrates with or manages Prometheus, Alertmanager, and other observability tooling
+- **OpenShift platform**: Runs on top of OpenShift Container Platform and provides cluster-wide observability
+
+## Exam-Relevant Points
+- The Cluster Observability Operator is a **separate operator** from the default Cluster Monitoring Operator
+- COO is an **optional, installable operator** — not part of the default OpenShift installation
+- Know the distinction between COO (newer, dedicated observability operator) and the built-in monitoring stack
+- COO has its own independent versioning ("1-latest") separate from the OpenShift platform version
+

entries/2026/03/05/en-documentation-builds_for_red_hat_openshift-17.md

@@ -0,0 +1,49 @@
+---
+source_url: https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.7
+source: sources/en-documentation-builds_for_red_hat_openshift-17.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:11
+
+
+
+## Overview
+
+Builds for Red Hat OpenShift is a standalone product (version 1.7) that provides build capabilities for OpenShift. This is the top-level documentation landing page, serving as a table of contents for the product's documentation set covering installation, configuration, usage, shared resources, authentication, observability, and lifecycle management.
+
+## Key Concepts
+
+- **Builds for Red Hat OpenShift** is a distinct product from OpenShift's built-in build system (BuildConfig/Build APIs) — it is separately installed, configured, and uninstalled via an operator.
+- The product is versioned independently (1.0 through 1.7), indicating it follows its own release cadence apart from OpenShift platform versions.
+- **Shared Resources CSI Driver** is a component that integrates with Builds, enabling shared resources to be mounted into build pods.
+- The product has its own **authentication model** for runtime operations, separate from but building on OpenShift's auth.
+- **Build controller observability** is a first-class concern with dedicated documentation, suggesting metrics/monitoring integration.
+
+## Commands and Syntax
+
+No specific commands on this landing page. The documentation sections map to operator lifecycle phases:
+
+1. **Install** — Deploy the Builds operator
+2. **Configure** — Set up build environments and defaults
+3. **Work with Builds** — Create and manage build workloads
+4. **Work with Shared Resources** — Configure CSI-based shared resources
+5. **Uninstall** — Remove the operator cleanly
+
+## Relationships
+
+- **Shipwright** — Builds for Red Hat OpenShift is the Red Hat productized version of the upstream Shipwright project.
+- **Tekton/OpenShift Pipelines** — Builds for Red Hat OpenShift uses Tekton TaskRuns under the hood to execute builds.
+- **OpenShift BuildConfig (legacy)** — This is the modern replacement/alternative to the built-in OpenShift build system (S2I, Docker, Custom strategies).
+- **Shared Resources CSI Driver** — A separate but tightly coupled component for injecting shared secrets/ConfigMaps into builds.
+- **OLM (Operator Lifecycle Manager)** — The product is installed and managed as an operator.
+
+## Exam-Relevant Points
+
+- Builds for Red Hat OpenShift is a **separately installable operator**, not part of the default OpenShift installation.
+- It is distinct from the legacy OpenShift `Build`/`BuildConfig` API — know the difference.
+- The documentation structure reveals the product's key components: the build controller, shared resources CSI driver, and authentication layer.
+- Shared Resources CSI Driver is documented as its own section, indicating it may be tested as a separate concept.
+- The product supports **observability** features for the build controller (likely Prometheus metrics).
+

entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md

@@ -0,0 +1,111 @@
+---
+source_url: https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.17/html/managing_alerts/managing-alerts-as-an-administrator
+source: sources/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:12
+
+## Overview
+This page covers how OpenShift Container Platform administrators manage alerts, silences, and alerting rules through the web console's Alerting UI. It details navigating the Administrator perspective, creating and modifying alerting rules for both core platform and user-defined projects, and managing silences to suppress alert notifications.
+
+## Key Concepts
+- **Alerting UI** has three main pages: **Alerts**, **Silences**, and **Alerting rules**, accessed via **Observe → Alerting** in the Administrator perspective
+- **Silences** suppress alert notifications for a defined duration; they are replicated across Alertmanager pods but can be lost without persistent storage
+- **Editing a silence** expires the existing one and creates a new one with updated configuration
+- **Expired silences** cannot be deleted; they are garbage collected after **120 hours**
+- Two resource types for platform alerting rules:
+  - **`AlertingRule`** (apiVersion: `monitoring.openshift.io/v1`) — for creating new platform alerting rules
+  - **`AlertRelabelConfig`** (apiVersion: `monitoring.openshift.io/v1`) — for modifying/relabeling existing platform alerts before Alertmanager routes them
+- **`PrometheusRule`** (apiVersion: `monitoring.coreos.com/v1`) — for user-defined project alerting rules
+- Both `AlertingRule` and `AlertRelabelConfig` **must** be created in the `openshift-monitoring` namespace
+- `PrometheusRule` resources go in the user's project namespace
+- A **project label is automatically enforced** on user-defined alerting rules, even if a rule with the same name exists in another project
+
+## Commands and Syntax
+
+**Create a platform alerting rule (`AlertingRule`):**
+```yaml
+apiVersion: monitoring.openshift.io/v1
+kind: AlertingRule
+metadata:
+  name: example
+  namespace: openshift-monitoring  # MUST be openshift-monitoring
+spec:
+  groups:
+  - name: example-rules
+    rules:
+    - alert: ExampleAlert
+      for: 1m
+      expr: vector(1)
+      labels:
+        severity: warning
+      annotations:
+        message: This is an example alert.
+```
+```bash
+oc apply -f example-alerting-rule.yaml
+```
+
+**Modify platform alerts with `AlertRelabelConfig`:**
+```yaml
+apiVersion: monitoring.openshift.io/v1
+kind: AlertRelabelConfig
+metadata:
+  name: watchdog
+  namespace: openshift-monitoring  # MUST be openshift-monitoring
+spec:
+  configs:
+  - sourceLabels: [alertname,severity]
+    regex: "Watchdog;none"
+    targetLabel: severity
+    replacement: critical
+    action: Replace
+```
+Relabel actions: `Replace` (default), `Keep`, `Drop`, `HashMod`, `LabelMap`, `LabelDrop`, `LabelKeep`
+
+**Create a user-defined project alerting rule (`PrometheusRule`):**
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: PrometheusRule
+metadata:
+  name: example-alert
+  namespace: ns1
+spec:
+  groups:
+  - name: example
+    rules:
+    - alert: VersionAlert
+      for: 1m
+      expr: version{job="prometheus-example-app"} == 0
+      labels:
+        severity: warning
+      annotations:
+        message: This is an example alert.
+```
+
+**Remove a user-defined alerting rule:**
+```bash
+oc -n <namespace> delete prometheusrule <alerting_rule>
+```
+
+## Relationships
+- **Alertmanager** receives and routes alerts; silences and `AlertRelabelConfig` modify what Alertmanager processes
+- **Persistent storage for Alertmanager** is required to prevent silence loss across pod restarts
+- **User-defined monitoring** must be enabled before creating `PrometheusRule` resources
+- **RBAC roles**: `cluster-admin` for full access; `cluster-monitoring-view` + `monitoring-alertmanager-edit` for non-admin silence management; `monitoring-rules-edit` for managing user-defined alerting rules
+- Platform alerting rules use the `monitoring.openshift.io/v1` API; user-defined rules use the `monitoring.coreos.com/v1` (Prometheus Operator) API
+
+## Exam-Relevant Points
+- `AlertingRule` and `AlertRelabelConfig` resources **must** be in the `openshift-monitoring` namespace — they are silently rejected otherwise
+- Platform alerting rules use `kind: AlertingRule`; user-defined project rules use `kind: PrometheusRule` — different API groups
+- `AlertRelabelConfig` modifies alerts **before** Alertmanager routes them (not after)
+- A silence **requires a comment** before it can be saved
+- Expired silences are garbage collected after **120 hours**
+- Silences are **replicated across Alertmanager pods** but require persistent storage to survive pod restarts
+- Non-admin users need both `cluster-monitoring-view` and `monitoring-alertmanager-edit` roles to manage silences
+- Non-admin users need the `monitoring-rules-edit` role to create alerting rules in their projects
+- If you create a custom `AlertingRule` based on an existing platform rule, you should **silence the original** to avoid conflicting alerts
+- Alerting rules require `alert`, `for`, `expr`, `labels.severity`, and `annotations.message` fields
+

entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-421.md

@@ -0,0 +1,44 @@
+---
+source_url: https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.21
+source: sources/en-documentation-monitoring_stack_for_red_hat_openshift-421.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:12
+
+## Overview
+The Monitoring stack for Red Hat OpenShift 4.21 is a dedicated documentation suite covering the built-in monitoring capabilities of OpenShift Container Platform. It spans core platform monitoring (cluster components) and user workload monitoring (application-level), built on Prometheus and Alertmanager, with guidance on configuration, metrics access, alerting, and troubleshooting.
+
+## Key Concepts
+- **Monitoring stack** is a separate product documentation set ("Monitoring stack for Red Hat OpenShift"), distinct from the main OCP docs but tightly integrated.
+- **Core platform monitoring** — monitors cluster infrastructure components; configured by cluster admins.
+- **User workload monitoring** — optional feature enabling non-admin users to monitor their own projects/namespaces.
+- **Cluster Monitoring Operator (CMO)** — the operator that manages the monitoring stack; has its own ConfigMap reference and alert reference.
+- **Prometheus** and **Alertmanager** are the underlying components of the monitoring stack.
+- **RHOSO integration** — special configuration exists for clusters running on Red Hat OpenStack Services on OpenShift (metric correlation).
+- **Observability** is a broader umbrella (Red Hat OpenShift Observability) that includes monitoring plus additional tooling for application and infrastructure performance analysis.
+
+## Commands and Syntax
+No specific CLI commands are provided on this landing page. The page serves as a table of contents pointing to sub-guides. Key configuration areas referenced:
+- Core platform monitoring configuration (ConfigMap-based via CMO)
+- User workload monitoring enablement and configuration
+- Alert and silence management
+- Metrics access configuration
+
+## Relationships
+- **Cluster Monitoring Operator** → manages Prometheus, Alertmanager, and related components
+- **User workload monitoring** → extends core platform monitoring to user namespaces; must be explicitly enabled
+- **Red Hat OpenShift Observability** → superset that includes monitoring plus logging, tracing, and other observability tools
+- **RHOSO** → specialized monitoring configuration for OpenStack-based OCP deployments
+- **Monitoring APIs** → documented under the main OCP 4.21 API reference, not the monitoring stack docs
+
+## Exam-Relevant Points
+- Monitoring is split into **core platform** (always on) and **user workload** (opt-in) — know the distinction.
+- The **Cluster Monitoring Operator** is the central operator; configuration is done via **ConfigMaps**, not CRDs.
+- User workload monitoring must be **explicitly enabled** for non-admin users to monitor their projects.
+- Prometheus and Alertmanager are the key components managed by the stack.
+- There is a **supported configuration** boundary — only documented configuration methods are supported (see "Support for monitoring").
+- Alerting rules are **built-in** and managed by the CMO; custom alerting rules can also be created.
+- OpenShift Observability is broader than just monitoring — distinguishing monitoring from the full observability suite is important.
+

entries/2026/03/05/en-documentation-openshift_cluster_manager-1-latest.md

@@ -0,0 +1,34 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_cluster_manager/1-latest
+source: sources/en-documentation-openshift_cluster_manager-1-latest.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:12
+
+## Overview
+This is the top-level landing page for **OpenShift Cluster Manager (OCM)** documentation (version 1-latest). It serves as a navigation hub pointing to the main guide for managing clusters, Red Hat Lightspeed integration, and reference material for subscriptions and pay-as-you-go billing.
+
+## Key Concepts
+- **OpenShift Cluster Manager (OCM)** is a Red Hat-hosted service for working with OpenShift clusters — creating, managing, and monitoring them from a central interface.
+- OCM is a **SaaS console** (accessible at console.redhat.com), distinct from the per-cluster OpenShift web console.
+- The primary documentation area is **"Managing Clusters"** — covering day-to-day cluster operations through OCM.
+- **Red Hat Lightspeed** is referenced as an integrated AI assistant capability within the Red Hat documentation ecosystem.
+- Subscription and billing models include traditional **Subscription Management** (via Subscription Central) and **Pay-as-You-Go** (via Red Hat Marketplace).
+
+## Commands and Syntax
+No commands or configuration syntax are present on this index page. Operational content lives under the linked "Managing Clusters" guide.
+
+## Relationships
+- **OpenShift Cluster Manager → Managed OpenShift services**: OCM is the control plane for ROSA (AWS), ARO (Azure), and OSD (GCP/AWS) managed clusters, as well as self-managed OCP clusters registered with Red Hat.
+- **Subscription Central**: Handles entitlements and subscription tracking for clusters managed through OCM.
+- **Red Hat Marketplace / Pay-as-You-Go**: Alternative consumption-based billing model for OpenShift clusters.
+- **Red Hat Lightspeed**: AI-powered documentation assistant integrated across Red Hat products.
+
+## Exam-Relevant Points
+- Know that **OpenShift Cluster Manager** is the centralized SaaS interface at `console.redhat.com` used to manage the lifecycle of OpenShift clusters.
+- Understand the distinction between OCM (fleet-level management) and the individual cluster's web console (cluster-level management).
+- Be aware that OpenShift supports both **subscription-based** and **pay-as-you-go** billing models.
+- OCM is relevant for both managed services (ROSA, ARO, OSD) and self-managed OCP clusters that are registered with Red Hat.
+

entries/2026/03/05/en-documentation-openshift_container_platform-410-html-single-storage-index.md

@@ -0,0 +1,89 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.10/html-single/storage/index
+source: sources/en-documentation-openshift_container_platform-410-html-single-storage-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:13
+
+## Overview
+This page provides a comprehensive overview of storage in OpenShift Container Platform 4.10, covering ephemeral and persistent storage concepts, the PV/PVC lifecycle, access modes, reclaim policies, volume types, and the Container Storage Interface (CSI). It serves as the foundational reference for configuring and managing storage in an OCP cluster.
+
+## Key Concepts
+
+- **Two storage categories**: Ephemeral storage (transient, pod-scoped) and Persistent storage (survives pod lifecycle)
+- **Persistent Volume (PV)**: Cluster-scoped resource representing a piece of storage, provisioned statically by an admin or dynamically via StorageClass
+- **Persistent Volume Claim (PVC)**: Project-scoped request for storage by a developer; once bound to a PV, that PV is scoped to the binding project's namespace
+- **PVs are not namespace-scoped** — they can be shared across the cluster, but once bound to a PVC they are effectively scoped to that PVC's namespace
+- **Access Modes**: ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP)
+- **Reclaim Policies**: `Retain` (manual cleanup), `Recycle` (deprecated in OCP 4), `Delete` (removes PV and external storage asset)
+- **Dynamically provisioned volumes are always deleted** when released
+- **Storage Object in Use Protection**: Prevents deletion of PVCs actively used by pods and PVs bound to PVCs (enabled by default)
+- **Ephemeral storage** uses two partitions: **root** (`/var/lib/kubelet/`, `/var/log/`) and optional **runtime** (overlay filesystems, image layers)
+- **Ephemeral storage provides no IOPS or throughput SLAs**
+- **Container Storage Interface (CSI)**: Vendor-neutral API for managing container storage across orchestration systems
+- **Dynamic Provisioning**: Creates storage volumes on-demand, eliminating need for admin pre-provisioning
+- **OpenShift Data Foundation**: Provides agnostic persistent storage supporting file, block, and object storage
+
+## Commands and Syntax
+
+**Monitor ephemeral storage:**
+```bash
+df -h /var/lib
+```
+
+**PV definition example:**
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv0001
+spec:
+  capacity:
+    storage: 5Gi
+  accessModes:
+    - ReadWriteOnce
+  persistentVolumeReclaimPolicy: Retain
+```
+
+**Delete a PV (manual reclaim):**
+```bash
+oc delete pv <pv-name>
+```
+
+**Change reclaim policy:**
+```bash
+oc patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
+```
+
+**List persistent volumes:**
+```bash
+oc get pv
+```
+
+## Relationships
+
+- **StorageClass** → enables Dynamic Provisioning → creates PVs automatically when PVCs are submitted
+- **PVC** → binds to → **PV** → backed by storage plugin (NFS, EBS, Cinder, vSphere, etc.)
+- **CSI** is the modern interface replacing in-tree volume plugins and FlexVolume
+- **OpenShift Data Foundation** provides the managed storage layer on top of these primitives
+- **Ephemeral storage** relates to node resource management, pod eviction, and resource quotas
+- **RBAC** controls who can provision and consume storage resources
+- **StatefulSets** depend on persistent storage for stateful application deployments
+
+## Exam-Relevant Points
+
+- **Recycle reclaim policy is deprecated in OCP 4** — dynamic provisioning is the recommended replacement
+- **Dynamically provisioned volumes always use the Delete reclaim policy**
+- **PVs are cluster-scoped; PVCs are project/namespace-scoped**
+- **A PV bound to a PVC cannot be bound to additional PVCs** — effectively one-to-one binding
+- **Storage Object in Use Protection is enabled by default** — prevents data loss from premature deletion
+- **Claims remain unbound indefinitely** if no matching PV exists (they do not fail — they wait)
+- **OCP binds PVCs to the smallest PV that matches** all criteria to minimize waste
+- **Four access modes**: RWO, ROX, RWX, RWOP — know which storage backends support which modes
+- **Supported PV plugins**: AWS EBS, AWS EFS, Azure Disk, Azure File, Cinder, Fibre Channel, GCE PD, HostPath, iSCSI, Local volume, NFS, OpenStack Manila, ODF, VMware vSphere, AliCloud Disk, IBM VPC Block
+- **Manual PV reclaim procedure**: delete PV → clean up data on storage asset → delete or reuse storage asset → create new PV
+- **`oc patch pv`** is the command to change reclaim policy on an existing PV
+- **Ephemeral storage** can cause pod eviction if local storage fills up; pods cannot request guaranteed local storage
+

entries/2026/03/05/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md

@@ -0,0 +1,66 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/cli_tools/openshift-cli-oc
+source: sources/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:13
+
+## Overview
+This page covers the OpenShift CLI (`oc`), the primary command-line tool for managing OpenShift Container Platform clusters. It details installation methods across platforms (Linux, Windows, macOS), authentication procedures, and basic usage commands for project and application management.
+
+## Key Concepts
+- The `oc` CLI is the primary tool for managing OCP projects and applications from the terminal
+- `oc` is ideal for: working with source code, scripting operations, and managing projects when the web console is unavailable
+- The `oc` binary must match the cluster version — earlier versions cannot complete all commands for OCP 4.15
+- When `oc` runs inside a pod without a namespace specified, it defaults to the pod's namespace
+- Authentication headers are only sent over HTTPS transport
+- HTTP proxy access is supported via `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables
+- The `--web` flag for `oc login` runs a localhost HTTP server (not HTTPS) — use with caution on multi-user workstations
+
+## Commands and Syntax
+
+**Installation:**
+- Binary download: `tar xvf <file>`, then move `oc` to a directory on `PATH`
+- RPM (RHEL 8 only, not RHEL 9): `yum install openshift-clients` (requires subscription and enabling `rhocp-4.15-for-rhel-8-x86_64-rpms` repo)
+- Homebrew (macOS): `brew install openshift-cli`
+- Web console: **?** → **Command Line Tools** → download appropriate binary
+
+**Authentication:**
+- `oc login -u user1` — interactive login with username/password
+- `oc login <cluster_url> --web` — browser-based login (opens browser automatically)
+- `oc login <cluster_url> --web --callback-port 8280` — specify callback port
+- Copy login command from web console (top-right username dropdown → **Copy login command**) — includes token
+
+**Common operations:**
+- `oc new-project my-project` — create a project
+- `oc new-app https://github.com/sclorg/cakephp-ex` — create an app from source
+- `oc get pods -o wide` — list pods with extended info
+- `oc logs <pod-name>` — view pod logs
+- `oc project` — show current project
+- `oc status` — show project status (services, deployments, build configs)
+- `oc api-resources` — list supported API resources
+- `oc help` — general help
+- `oc <command> --help` — help for a specific command
+- `oc explain <resource>` — describe fields of a resource
+
+## Relationships
+- **Web Console**: Alternative interface; also provides CLI download links and "Copy login command" feature
+- **Projects/Namespaces**: `oc` operates within the context of a project; `oc new-project` creates them
+- **Source-to-Image (S2I)**: `oc new-app` with a Git URL triggers S2I builds
+- **RBAC/Authentication**: `oc login` authenticates via identity providers configured on the cluster
+- **Subscription Manager**: RPM installation requires an active OCP subscription via RHSM
+- **kubectl**: `oc` extends `kubectl` with OpenShift-specific commands (projects, new-app, etc.)
+
+## Exam-Relevant Points
+- **RPM install is NOT supported on RHEL 9** — must use binary download instead
+- The `oc` version must match the cluster version (earlier versions are incompatible)
+- `oc login --web` uses HTTP (not HTTPS) on localhost — security warning for shared workstations
+- `oc status --suggest` provides additional recommendations beyond basic status
+- Proxy environment variables (`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) are respected by `oc`
+- `oc api-resources` shows short names (e.g., `cm` for ConfigMaps, `cs` for ComponentStatus) and whether resources are namespaced
+- The web console login command (Copy login command) includes an authentication token — avoids interactive prompts
+- macOS arm64 requires a specific binary variant (`OpenShift v4.15 macOS arm64 Client`)
+- When running `oc` inside a pod, the pod's namespace is used by default if none is specified
+

entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md

@@ -0,0 +1,141 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/operators/understanding-operators
+source: sources/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:14
+
+## Overview
+
+This page covers the foundational concepts of Operators in OpenShift Container Platform 4.15, including what Operators are, the Operator Framework ecosystem (SDK, OLM, Registry, OperatorHub), the Operator maturity model, packaging formats (bundle format and file-based catalogs), and the catalog system used by Operator Lifecycle Manager (OLM) to discover and install Operators.
+
+## Key Concepts
+
+- **Operators** encode human operational knowledge into software; they package, deploy, and manage Kubernetes applications using Kubernetes APIs and CRDs
+- **Operator Framework** consists of four components: Operator SDK, OLM, Operator Registry, and OperatorHub
+- **OLM** (Operator Lifecycle Manager) controls installation, upgrade, and RBAC of Operators; deployed by default in OCP 4.15
+- **Operator maturity model** defines five phases: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot
+- **Bundle format**: a single Operator version packaged as a non-runnable container image containing Kubernetes manifests and metadata
+- **Bundle requirements**: at least one channel, exactly one CSV per bundle, owned CRDs must be present
+- **File-based catalogs (FBC)**: plain text (JSON/YAML) declarative format replacing deprecated SQLite format; default since OCP 4.11
+- **FBC properties**: editability, composability, extensibility
+- **Three FBC schemas**: `olm.package` (one per package), `olm.channel` (at least one per package), `olm.bundle` (one or more per package)
+- **olm.deprecations schema**: marks packages, channels, or bundles as deprecated
+- **Dependency types**: `olm.package` (version-based), `olm.gvk` (group/version/kind), `olm.constraint` (generic)
+- **Channel upgrade edges**: `replaces`, `skips`, `skipRange` control upgrade paths
+- **CatalogSource** object references a catalog image; OLM polls it at regular intervals
+- **`.indexignore`** files work like `.gitignore` to exclude non-catalog files
+- **All `olm.*` schemas are reserved** for OLM-defined schemas; custom schemas need unique prefixes
+- Service brokers vs Operators: brokers are not long-running, cannot handle Day 2 operations
+
+## Commands and Syntax
+
+```bash
+# opm CLI - create and maintain Operator catalogs
+opm validate <catalog-dir>          # Validate a file-based catalog
+opm init <package-name>             # Initialize FBC package
+opm render <bundle-image>           # Render bundle into FBC format
+
+# Build bundle image
+podman build -f bundle.Dockerfile -t <registry>/<bundle-image>:<tag>
+podman push <registry>/<bundle-image>:<tag>
+```
+
+**Bundle directory structure:**
+```
+etcd
+├── manifests
+│   ├── etcdcluster.crd.yaml
+│   └── etcdoperator.clusterserviceversion.yaml
+└── metadata
+    ├── annotations.yaml
+    └── dependencies.yaml
+```
+
+**File-based catalog structure:**
+```
+catalog
+├── packageA
+│   └── index.yaml
+├── packageB
+│   ├── .indexignore
+│   ├── index.yaml
+│   └── objects/
+└── packageC
+    ├── index.json
+    └── deprecations.yaml
+```
+
+**annotations.yaml keys:**
+```yaml
+annotations:
+  operators.operatorframework.io.bundle.mediatype.v1: "registry+v1"
+  operators.operatorframework.io.bundle.manifests.v1: "manifests/"
+  operators.operatorframework.io.bundle.metadata.v1: "metadata/"
+  operators.operatorframework.io.bundle.package.v1: "test-operator"
+  operators.operatorframework.io.bundle.channels.v1: "beta,stable"
+  operators.operatorframework.io.bundle.channel.default.v1: "stable"
+```
+
+**dependencies.yaml example:**
+```yaml
+dependencies:
+  - type: olm.package
+    value:
+      packageName: prometheus
+      version: ">0.27.0"
+  - type: olm.gvk
+    value:
+      group: etcd.database.coreos.com
+      kind: EtcdCluster
+      version: v1beta2
+```
+
+**olm.deprecations example:**
+```yaml
+schema: olm.deprecations
+package: my-operator
+entries:
+  - reference:
+      schema: olm.package
+    message: "Package is end of life"
+  - reference:
+      schema: olm.channel
+      name: alpha
+    message: "Channel is deprecated"
+  - reference:
+      schema: olm.bundle
+      name: my-operator.v1.0.0
+    message: "Bundle has a CVE"
+```
+
+## Relationships
+
+- **OLM** uses **CatalogSource** objects to reference catalog images and poll for updates
+- **Operator SDK** supports building Operators with **Helm**, **Go**, and **Ansible** (mapped to maturity model capabilities)
+- **Bundle images** are stored in **container registries** (e.g., Quay) and referenced by catalogs
+- **CRDs** define the custom resources that Operators manage; CSV declares which CRDs an Operator owns/requires
+- **Channels** provide upgrade paths; **Subscriptions** connect users to channels
+- **File-based catalogs** replaced **SQLite database format** (deprecated since OCP 4.11)
+- **`opm` CLI** bridges bundle format and catalog management
+- Connects to: CatalogSource configuration, Subscription objects, OperatorHub UI, disconnected installation mirroring
+
+## Exam-Relevant Points
+
+- OLM is deployed **by default** in OpenShift Container Platform 4.15
+- OperatorHub is deployed **by default** in OpenShift Container Platform
+- The five Operator maturity levels: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot
+- A bundle must have **exactly one CSV** and **at least one channel**
+- File-based catalogs became the **default format since OCP 4.11**; SQLite format is **deprecated**
+- Three required FBC schemas per package: `olm.package` (exactly one), `olm.channel` (at least one), `olm.bundle` (one or more)
+- **`annotations.yaml` is authoritative** over other sources in case of mismatch
+- Three dependency types: `olm.package`, `olm.gvk`, `olm.constraint`
+- **`skipRange`** prunes skipped versions from the update graph — they become uninstallable
+- Use both `skipRange` and `replaces` together to skip versions while keeping them installable
+- Duplicate packages/bundles within a package are **not permitted** in file-based catalogs
+- `opm validate` is the command to validate catalogs
+- Optional bundle objects (ConfigMap, Secret, Service, ServiceMonitor, etc.) have their lifecycle managed by OLM alongside the CSV
+- The `olm.deprecations` schema requires a `package` value matching an existing `olm.package`, and each entry's `message` is required
+

entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md

@@ -0,0 +1,148 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/operators/user-tasks
+source: sources/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:14
+
+## Overview
+This page covers user-facing tasks for working with Operators in OpenShift Container Platform 4.15, including creating applications from installed Operators, installing Operators from OperatorHub (via web console and CLI), and managing Operator updates (approval, upgrading, and deletion). It focuses on the self-service capabilities available to developers and non-admin users through Operator Lifecycle Manager (OLM).
+
+## Key Concepts
+
+- **Cluster Service Version (CSV)**: The resource that represents a particular version of an installed Operator; used to launch and manage the Operator's software. Check with `oc get csv`.
+- **PackageManifest**: Represents an Operator available in a catalog; describes install modes, channels, and versions. Lives in `openshift-marketplace`.
+- **OperatorGroup**: Defines target namespaces for RBAC generation; only **one OperatorGroup per namespace** is allowed. Required for `SingleNamespace` install mode; `openshift-operators` already has `global-operators` for `AllNamespaces` mode.
+- **Subscription**: The object that subscribes a namespace to an Operator from a catalog source, specifying channel, source, and approval strategy.
+- **Install Modes**: `OwnNamespace`, `SingleNamespace`, `MultiNamespace`, `AllNamespaces` — each Operator declares which modes it supports.
+- **Approval Strategy**: **Automatic** (OLM upgrades automatically) vs **Manual** (admin must approve each update via InstallPlan). Manual is recommended for cloud token auth clusters (AWS STS, Entra Workload ID).
+- **Catalog Sources**: Default catalogs — Red Hat Operators, Certified Operators, Community Operators — served from `openshift-marketplace`.
+- Users with the `edit` role can create/manage/delete application instances from installed Operators in a self-service manner.
+- Community Operators are **not certified by Red Hat**; a warning must be acknowledged.
+- Installing an Operator with Manual approval in a namespace causes **all Operators in that namespace** to use Manual approval and update together. Install into separate namespaces for independent updates.
+
+## Commands and Syntax
+
+**List installed Operators:**
+```bash
+oc get csv
+```
+
+**List available Operators from OperatorHub:**
+```bash
+oc get packagemanifests -n openshift-marketplace
+```
+
+**Inspect an Operator's install modes, channels, versions:**
+```bash
+oc describe packagemanifests <operator_name> -n openshift-marketplace
+```
+
+**Filter by specific catalog:**
+```bash
+oc get packagemanifest \
+  --selector=catalog=<catalogsource_name> \
+  --field-selector metadata.name=<operator_name> \
+  -n <catalog_namespace> -o yaml
+```
+
+**Grant edit role for self-service Operator usage:**
+```bash
+oc policy add-role-to-user edit <user> -n <target_project>
+```
+
+**OperatorGroup for SingleNamespace mode:**
+```yaml
+apiVersion: operators.coreos.com/v1
+kind: OperatorGroup
+metadata:
+  name: <operatorgroup_name>
+  namespace: <namespace>
+spec:
+  targetNamespaces:
+  - <namespace>
+```
+
+**Subscription object:**
+```yaml
+apiVersion: operators.coreos.com/v1alpha1
+kind: Subscription
+metadata:
+  name: <subscription_name>
+  namespace: <namespace_per_install_mode>  # openshift-operators for AllNamespaces
+spec:
+  channel: <channel_name>
+  name: <operator_name>
+  source: <catalog_name>
+  sourceNamespace: openshift-marketplace
+  config:
+    env: [...]
+    envFrom: [...]
+    volumes: [...]
+    volumeMounts: [...]
+    tolerations: [...]
+    resources: {requests: {...}, limits: {...}}
+    nodeSelector: {key: value}
+```
+
+**Pin to a specific version (requires Manual approval):**
+```yaml
+spec:
+  channel: stable-3.7
+  installPlanApproval: Manual
+  startingCSV: example-operator.v3.7.10
+```
+
+**AWS STS config in Subscription:**
+```yaml
+spec:
+  config:
+    env:
+    - name: ROLEARN
+      value: "<role_arn>"
+```
+
+**Entra Workload ID config in Subscription:**
+```yaml
+spec:
+  config:
+    env:
+    - name: CLIENTID
+      value: "<client_id>"
+    - name: TENANTID
+      value: "<tenant_id>"
+    - name: SUBSCRIPTIONID
+      value: "<subscription_id>"
+```
+
+**Verify installation:**
+```bash
+oc describe subscription <subscription_name> -n <namespace>
+oc describe operatorgroup <operatorgroup_name> -n <namespace>
+```
+
+## Relationships
+
+- **OLM (Operator Lifecycle Manager)**: The backend that manages Operator installation, upgrades, and lifecycle — Subscriptions, CSVs, and InstallPlans are all OLM resources.
+- **OperatorHub**: The discovery UI frontend that works with OLM; sources from CatalogSources.
+- **RBAC / Permissions**: Cluster admins must delegate Operator installation permissions; the `edit` role grants self-service instance management.
+- **Cloud Provider Auth**: AWS STS and Microsoft Entra Workload ID clusters require special Subscription config and Manual approval strategy.
+- **CatalogSource / openshift-marketplace**: The namespace housing default catalog sources that PackageManifests are read from.
+- **InstallPlan**: Created by OLM when Manual approval is set; must be approved to complete installation or upgrade.
+
+## Exam-Relevant Points
+
+- `oc get packagemanifests -n openshift-marketplace` lists all available Operators — know this command.
+- **Only one OperatorGroup per namespace** — this is a hard constraint.
+- For `SingleNamespace` mode, you must create an OperatorGroup manually (CLI); the web console handles this automatically.
+- For `AllNamespaces` mode, `openshift-operators` namespace already has `global-operators` group — skip OperatorGroup creation.
+- The `Subscription` object requires: `channel`, `name`, `source`, `sourceNamespace`.
+- To install a **specific version**: set `startingCSV` and `installPlanApproval: Manual`.
+- **Manual approval in a namespace affects all Operators in that namespace** — they all update together. Use separate namespaces for independent updates.
+- AWS STS / Entra Workload ID clusters **must use Manual approval** for Operator subscriptions.
+- The `config` section of a Subscription can set `env`, `envFrom`, `volumes`, `volumeMounts`, `tolerations`, `resources`, and `nodeSelector` on the Operator pod.
+- After installation, CSV status should show **Succeeded** in the target namespace (or **Copied** in other namespaces for AllNamespaces mode).
+- The `edit` role is what grants users self-service ability to create Operator-managed application instances.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-index.md

@@ -0,0 +1,31 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/index
+source: sources/en-documentation-openshift_container_platform-417-html-about-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:14
+
+## Overview
+This is the landing page for the "About" section of OpenShift Container Platform 4.17 documentation. It introduces OCP as a platform and serves as the entry point to the product's feature overview. The page itself contains minimal content — it primarily links to the full introduction document.
+
+## Key Concepts
+- **OpenShift Container Platform (OCP)** is a Red Hat product built on Kubernetes for deploying and managing containerized applications at scale.
+- **Version 4.17** is the documented release; OCP has a long version history spanning 3.x through 4.x lines.
+- Documentation is maintained by the **Red Hat OpenShift Documentation Team**.
+- The "About" section provides a **feature overview** of the platform — it is the conceptual starting point before operational docs.
+
+## Commands and Syntax
+No commands or configuration syntax are present on this page.
+
+## Relationships
+- This is the **root "About" page** — it connects to deeper introductory topics covering OCP architecture, features, and platform concepts.
+- It sits above operational documentation sections (installation, networking, storage, security, etc.).
+- The version selector shows OCP spans **3.x (legacy)** through **4.x (current)** — the 3.x to 4.x transition was a major architectural shift (from standalone orchestration to Kubernetes-native).
+
+## Exam-Relevant Points
+- OCP 4.x is the current platform generation; know that it is **Kubernetes-based**.
+- The version numbering convention: **4.17** is a specific minor release of OCP 4.
+- Red Hat maintains formal documentation per version — version-specific behavior differences can appear on exams.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md

@@ -0,0 +1,52 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/learn_more_about_openshift
+source: sources/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:15
+
+## Overview
+This page serves as a learning roadmap for OpenShift Container Platform 4.17, organizing documentation resources by persona and task area. It maps out what cluster administrators, developers, SREs, and other roles need to learn, covering architecture, installation, cluster management, observability, storage, application development, and hosted control planes.
+
+## Key Concepts
+- **Persona-based organization**: Documentation is structured around roles — Cluster Administrator, Developer, App SRE — each with distinct learning paths
+- **Architecture foundations**: Enterprise Kubernetes, OVN-Kubernetes networking, security/compliance, and backup/restore form the architectural base
+- **Installation modes**: Standard installation, restricted/disconnected network installation, and installation into existing networks (existing VPC/VNet) are distinct paths
+- **Cluster capabilities**: OpenShift 4.17 supports optional cluster capabilities that can be selectively enabled
+- **Machine management**: Compute and control plane machines are managed via machine sets, with support for machine health checks and autoscaling
+- **Hosted control planes (HCP)**: A deployment model where control planes run as hosted workloads, deployable on OpenShift Virtualization, AWS, bare metal, IBM Z, and IBM Power
+- **Observability stack**: Includes distributed tracing (Red Hat build of OpenTelemetry), Network Observability, monitoring, and power monitoring (Tech Preview)
+- **Developer tooling**: Includes odo (developer CLI), OpenShift Pipelines (CI/CD), Dev Spaces, Topology view, and application export capabilities
+
+## Commands and Syntax
+No specific commands on this page — it is a navigation/index page. Key referenced tools and interfaces:
+- **odo** — developer-focused CLI for application development
+- **OpenShift Pipelines** — CI/CD pipeline creation
+- **OpenShift Update Service** — cluster updates in disconnected environments
+- **Machine API** — programmatic machine management
+- **CRDs** — extending cluster with custom resource definitions
+
+## Relationships
+- **Installation → Restricted Networks**: Disconnected installs require image mirroring; supported on AWS, GCP, vSphere, IBM Cloud, IBM Z/LinuxONE, IBM Power, bare metal
+- **Cluster Admin → Operators**: Operators are central to managing cluster components and extending functionality
+- **Networking → CNO**: Cluster Network Operator manages networking; supports multiple network interfaces and network policy
+- **Observability → Monitoring**: Remote health monitoring, distributed tracing, and network observability are complementary monitoring capabilities
+- **Hosted Control Planes → Virtualization/Cloud**: HCP can run on OpenShift Virtualization, AWS, bare metal, IBM Z, IBM Power — and in disconnected environments
+- **Developer → Builds/Images**: Application development ties into build strategies, image management, and deployment mechanisms
+- **Storage → CSI/ODF**: Storage management connects to Red Hat OpenShift Data Foundation
+
+## Exam-Relevant Points
+- OpenShift 4.17 has **optional cluster capabilities** that can be selectively enabled/disabled
+- **Disconnected/restricted network** installations require mirroring installation images
+- Installation into **existing VPC** (AWS, GCP) or **existing VNet** (Azure) is a supported pattern
+- Machine management uses **machine sets** for both compute and control plane nodes
+- **Machine health checks** and **cluster autoscaling** are distinct but related features
+- Cluster updates can be performed via **web console**, **CLI**, or **OpenShift Update Service** (disconnected)
+- **Hosted control planes** are a distinct deployment model with specific platform support and sizing requirements
+- **RHCOS image layering** is available as an advanced installation capability
+- **FIPS mode** is an installation-time option
+- **Resource quotas** and **pruning** are key cluster management tasks
+- **Network Observability** and **Power Monitoring** (Tech Preview) are part of the observability stack
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-oke-about.md

@@ -0,0 +1,43 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/oke-about
+source: sources/en-documentation-openshift_container_platform-417-html-about-oke-about.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:15
+
+## Overview
+OpenShift Kubernetes Engine (OKE), formerly Red Hat OpenShift Container Engine, is a lower-cost subset of OpenShift Container Platform (OCP). It uses the same binary distribution and installation process as OCP but offers a reduced feature set focused on core Kubernetes orchestration, enterprise security, and infrastructure services — excluding developer-oriented tools, service mesh, serverless, pipelines, and logging.
+
+## Key Concepts
+- **Same binary, different entitlement**: OKE and OCP are the same download/product; OKE is a subscription that limits which features are supported, not a separate binary.
+- **Renamed in April 2020**: "OpenShift Container Engine" → "OpenShift Kubernetes Engine"
+- **Includes**: Automated installers (IPI/UPI), OTA upgrades, enterprise Kubernetes, `oc`/`kubectl`, OLM, admin console, cluster monitoring (Prometheus), OpenShift Virtualization, RHEL/RHCOS entitlements, all storage/network plugins, Helm, OVN/OVS SDN, MetalLB, Multus, Route API, HAProxy ingress, Compliance Operator, Local Storage Operator, SR-IOV, VPA, OADP, embedded registry, OperatorHub
+- **Excludes (requires OCP)**: Developer console, developer catalog, S2I/builder automation, OpenShift Pipelines (Jenkins/Tekton), Service Mesh (Istio/Kiali), Distributed Tracing, Serverless (Knative/Kourier), Platform Logging, User Workload Monitoring, OpenShift GitOps, Dev Spaces, `odo` CLI, sandboxed containers, Web Terminal, Migration Toolkit for Containers
+- **Separate subscription required (for both OKE and OCP)**: RHACM, ACS, ODF, Red Hat Quay, Gatekeeper, Ansible Automation Platform, various middleware/integration products
+- **Windows Containers**: OKE includes the Community Windows Machine Config Operator; OCP includes the Red Hat-supported version (separate subscription)
+
+## Commands and Syntax
+No unique commands — OKE uses the same `oc`, `kubectl`, and installer tooling as OCP. The difference is purely a subscription/support entitlement.
+
+## Relationships
+- **OCP superset**: OKE is a strict subset of OCP; understanding OKE means knowing what OCP features are excluded
+- **OpenShift Virtualization**: Included in OKE (kubevirt-based)
+- **ODF**: Compatible with OKE but requires separate purchase
+- **RHACM**: Compatible with OKE but requires separate purchase
+- **Red Hat Quay**: Compatible with OKE but requires separate purchase
+- **Networking**: Full CNI, OVN-Kubernetes, Multus, Network Policy support — but no Service Mesh or Kourier
+- **Monitoring**: Cluster monitoring included; User Workload Monitoring excluded
+- **Logging**: Log forwarding included; Platform Logging (Elasticsearch/Fluentd/Kibana stack) excluded
+
+## Exam-Relevant Points
+- OKE and OCP are the **same binary download** — the difference is subscription entitlement only
+- OKE **includes** OpenShift Virtualization, cluster monitoring, OLM, admin console, all storage plugins, full networking (OVN, Multus, Network Policy, egress controls)
+- OKE **excludes** the developer experience: no developer console, no S2I, no Pipelines, no `odo`, no Dev Spaces
+- OKE **excludes** Service Mesh, Serverless, Distributed Tracing, Platform Logging, and sandboxed containers
+- **User Workload Monitoring** is NOT included in OKE (cluster monitoring IS included)
+- **Log forwarding** is included in OKE; **Platform Logging** is not
+- OKE receives the **same SLAs, bug fixes, and CVE protection** as OCP
+- Products requiring **separate subscriptions regardless of OKE or OCP**: RHACM, ACS, ODF, Quay, Gatekeeper
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md

@@ -0,0 +1,13 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/providing-feedback-on-red-hat-documentation
+source: sources/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md
+---
+# En Documentation Openshift_Container_Platform 417 Html About Providing Feedback 
+
+**Date:** 2026-03-05
+**Time:** 13:15
+
+
+
+This page is just about how to submit documentation feedback via Jira — it has no technical content relevant to OpenShift expertise or certification. There's nothing worth summarizing into study notes from this page. Let me skip it.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-welcome-index.md

@@ -0,0 +1,29 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/welcome-index
+source: sources/en-documentation-openshift_container_platform-417-html-about-welcome-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:15
+
+## Overview
+This is the top-level landing page for OpenShift Container Platform 4.17 documentation. It serves as an entry point and navigation hub, directing users to explore OCP features via the navigation bar or curated task-based links.
+
+## Key Concepts
+- OpenShift Container Platform (OCP) is a Red Hat product with documentation spanning versions 3.0 through 4.21.
+- Version 4.17 is one of many supported releases, each with its own documentation set.
+- Documentation is available in multi-page, single-page, and PDF formats.
+
+## Commands and Syntax
+No commands or configuration syntax on this page.
+
+## Relationships
+- This is the root of the OCP 4.17 doc tree; all other 4.17 topics branch from here.
+- Links to the "Learn more about OpenShift Container Platform" task-oriented guide for onboarding.
+- Part of the broader Red Hat product documentation ecosystem.
+
+## Exam-Relevant Points
+- OCP versioning follows a `major.minor` scheme (e.g., 4.17); knowing which version you're working with matters for exam scenarios.
+- Documentation availability varies by version — not all docs exist for all versions.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about.md

@@ -0,0 +1,31 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about
+source: sources/en-documentation-openshift_container_platform-417-html-about.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:16
+
+## Overview
+This is the landing page for the "About" section of OpenShift Container Platform 4.17 documentation. It serves as an introduction to OpenShift Container Platform and provides an overview of its features. The page itself contains minimal content — it is primarily a navigation entry point.
+
+## Key Concepts
+- **OpenShift Container Platform (OCP)** is a Red Hat product built on Kubernetes for enterprise container orchestration.
+- Version **4.17** is the documented release on this page.
+- OCP has a long version history spanning from **3.0** through **4.21**, indicating a mature, actively developed platform.
+- The version jump from **3.x to 4.x** reflects the major architectural shift from standalone Docker/Kubernetes to an operator-driven, immutable infrastructure model (RHEL CoreOS, Cluster Version Operator).
+
+## Commands and Syntax
+None — this is an introductory/overview page with no commands or configuration syntax.
+
+## Relationships
+- This page is the entry point to the broader OCP documentation set, which covers installation, networking, storage, security, operators, CI/CD, and cluster management.
+- It connects to the **Legal Notice** for Red Hat documentation licensing.
+- The "About" section typically leads into topics like OCP architecture, platform lifecycle, and feature highlights.
+
+## Exam-Relevant Points
+- OCP 4.x is the current major version family; know that 4.17 exists as a supported release.
+- Red Hat maintains documentation across many versions simultaneously (3.x and 4.x lines), which reflects the product's enterprise support lifecycle (EUS, standard, and extended support).
+- Understanding the version you are working with is critical — exam questions often reference specific version capabilities.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md

@@ -0,0 +1,52 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/associating-secondary-interfaces-metrics-to-network-attachments
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:16
+
+## Overview
+
+This page describes how OpenShift administrators can associate secondary network interface metrics with their corresponding `NetworkAttachmentDefinition` resources using the `pod_network_name_info` metric. This solves the problem of identifying which secondary interface (added via Multus CNI) belongs to which network when monitoring container network metrics.
+
+## Key Concepts
+
+- **Secondary interfaces** are additional network interfaces added to pods (e.g., via Multus CNI); their names depend on the order they are added, making identification difficult from metrics alone.
+- **Network Metrics Daemon** is a daemonset that collects and publishes network-related metrics, supplementing kubelet's built-in `container_network_*` metrics.
+- **`pod_network_name_info`** is a gauge metric with a fixed value of `0`, published by the Network Metrics Daemon. Its purpose is to carry labels that map interface names to network attachment definitions.
+- The `network_name` label is derived from the `k8s.v1.cni.cncf.io/network-status` annotation added by Multus — formatted as `<nad-namespace>/<nad-name>`.
+- Standard kubelet metrics (e.g., `container_network_receive_bytes_total`) include pod name, namespace, and interface name, but do **not** identify the network purpose of the interface.
+
+## Commands and Syntax
+
+**PromQL join pattern** — enrich any `container_network_*` metric with the network name:
+
+```promql
+(container_network_receive_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )
+```
+
+This pattern uses `group_left(network_name)` to pull the `network_name` label from `pod_network_name_info` onto the existing container network metric, joining on `namespace`, `pod`, and `interface`.
+
+**Example metric output:**
+
+```
+pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
+```
+
+## Relationships
+
+- **Multus CNI**: Adds secondary interfaces and the `k8s.v1.cni.cncf.io/network-status` annotation that this metric relies on.
+- **NetworkAttachmentDefinition (NAD)**: The network name label is derived from the NAD resource name and namespace; different NADs distinguish different network classes/CNIs.
+- **Prometheus / Monitoring stack**: The PromQL queries assume the OpenShift monitoring stack (Prometheus) is scraping these metrics.
+- **Kubelet metrics**: `pod_network_name_info` is designed to be joined with existing kubelet `container_network_*` metrics — it has no value on its own.
+
+## Exam-Relevant Points
+
+- The `pod_network_name_info` metric always has a fixed value of **0** — it exists solely as a label carrier for PromQL joins.
+- The `network_name` label format is `<namespace>/<NetworkAttachmentDefinition name>`.
+- The PromQL join technique uses `+ on(namespace,pod,interface) group_left(network_name)` to enrich existing container network metrics.
+- There are **8** standard kubelet `container_network_*` metrics (4 receive, 4 transmit: bytes, errors, packets, packets_dropped).
+- Without `pod_network_name_info`, secondary interface metrics are ambiguous because interface names (e.g., `net0`) don't indicate which network they belong to.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md

@@ -0,0 +1,99 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/changing-cluster-network-mtu
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:17
+
+## Overview
+This page describes how to change the maximum transmission unit (MTU) for an OpenShift Container Platform cluster network after installation. The process is disruptive, requiring multiple rolling reboots of all cluster nodes, and is only supported with the OVN-Kubernetes network plugin. The migration involves a multi-step process: initiating the migration via CNO configuration, updating hardware MTU on nodes, and finalizing the migration.
+
+## Key Concepts
+- **Hardware MTU** vs **Cluster Network MTU**: The cluster network MTU is always less than the hardware MTU to account for overlay overhead. For OVN-Kubernetes, the overhead is **100 bytes**.
+- MTU is auto-detected during installation from the primary network interface; post-install changes follow a migration workflow.
+- **Only OVN-Kubernetes** supports changing the MTU value post-installation.
+- If nodes have different MTU values, the cluster network MTU must be set to the **lowest node MTU minus the overlay overhead** (e.g., nodes with 9001 and 1500 → cluster MTU = 1400).
+- The migration requires **at least two rolling reboots** of all nodes (one to prepare, one to finalize).
+- You **cannot roll back** MTU during migration, only after migration completes.
+- The Machine Config Operator (MCO) reboots **one node per pool at a time** by default.
+- Use `ip -d link` to verify the maximum MTU (`maxmtu`) accepted by a network interface.
+
+## Commands and Syntax
+
+**Check current cluster MTU:**
+```bash
+oc describe network.config cluster
+```
+
+**Find primary network interface on a node:**
+```bash
+oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
+```
+
+**Begin MTU migration (patch CNO):**
+```bash
+oc patch Network.operator.openshift.io cluster --type=merge --patch \
+  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
+```
+- `<overlay_from>`: current cluster network MTU
+- `<overlay_to>`: target cluster network MTU (must be `<machine_to>` minus 100 for OVN-Kubernetes)
+- `<machine_to>`: target hardware MTU
+
+**Check machine config pool status:**
+```bash
+oc get machineconfigpools
+# Success: UPDATED=true, UPDATING=false, DEGRADED=false
+```
+
+**Verify node machine config state:**
+```bash
+oc describe node | egrep "hostname|machineconfig"
+```
+
+**Finalize MTU migration:**
+```bash
+oc patch Network.operator.openshift.io cluster --type=merge --patch \
+  '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
+```
+
+**Verify node interface MTU after migration:**
+```bash
+oc adm node-logs <node> -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep <interface> | head -1
+```
+
+**DHCP MTU configuration (dnsmasq):**
+```
+dhcp-option-force=26,<mtu>
+```
+
+**NetworkManager conf.d file format:**
+```ini
+[connection-<interface>-mtu]
+match-device=interface-name:<interface>
+ethernet.mtu=<mtu>
+```
+
+**Butane config** creates MachineConfig objects that place the NetworkManager MTU config at `/etc/NetworkManager/conf.d/99-<interface>-mtu.conf` with separate configs for `master` and `worker` roles.
+
+## Relationships
+- **Cluster Network Operator (CNO)**: Validates migration parameters and writes temporary network configuration.
+- **Machine Config Operator (MCO)**: Performs rolling reboots during migration steps; applies MachineConfig objects.
+- **OVN-Kubernetes**: The only supported network plugin for MTU changes; has 100-byte overlay overhead.
+- **Butane**: Used to generate MachineConfig YAML from `.bu` config files for NetworkManager settings.
+- **NetworkManager**: Manages interface-level MTU on RHCOS nodes.
+- Related to bare-metal/PXE installation networking, DHCP configuration, and jumbo frame support on switches/hypervisors.
+
+## Exam-Relevant Points
+- OVN-Kubernetes overlay overhead is exactly **100 bytes** — cluster MTU = hardware MTU - 100.
+- Only **OVN-Kubernetes** supports post-install MTU changes (not OpenShift SDN).
+- The migration is a **3-phase process**: (1) patch CNO with migration spec, (2) update hardware MTU on nodes, (3) finalize by setting `spec.migration` to `null` and updating `ovnKubernetesConfig.mtu`.
+- The command to check current MTU is `oc describe network.config cluster`.
+- The `Network.operator.openshift.io` resource (not `network.config`) is patched for migration.
+- MCO updates **one machine per pool at a time** by default.
+- Successful node update: `UPDATED=true`, `UPDATING=false`, `DEGRADED=false`.
+- Node readiness is confirmed when `currentConfig` equals `desiredConfig` and state is `Done`.
+- Three methods for hardware MTU: NetworkManager connection profile (default), DHCP, kernel command line/PXE.
+- With mixed-MTU nodes, always use the **lowest** MTU minus overhead.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md

@@ -0,0 +1,38 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/index
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:17
+
+## Overview
+This is the landing page for the Advanced Networking section of OpenShift Container Platform 4.17 documentation. It serves as an index for specialized networking topics beyond basic cluster networking, covering MTU changes, connectivity verification, Stream Control Transmission Protocol (SCTP), Precision Time Protocol (PTP) hardware, and secondary interface metrics.
+
+## Key Concepts
+- **Advanced networking** is a distinct category from basic OCP networking, covering specialized use cases
+- Topics grouped under advanced networking include:
+  - **MTU changes** — modifying Maximum Transmission Unit size for cluster networks
+  - **Connectivity verification** — validating network connectivity within the cluster
+  - **SCTP (Stream Control Transmission Protocol)** — a transport-layer protocol alternative to TCP/UDP, relevant for telecom workloads
+  - **PTP (Precision Time Protocol) hardware** — hardware-based time synchronization for latency-sensitive workloads
+  - **Secondary interface metrics** — monitoring and metrics for additional (non-primary) network interfaces on pods
+
+## Commands and Syntax
+No commands or configuration syntax provided on this landing page — content is in the sub-pages.
+
+## Relationships
+- Falls under the broader **Networking** domain in OCP
+- **SCTP and PTP** are particularly relevant to **telecom/5G/NFV** use cases (closely related to OCP's role in edge and telco deployments)
+- **Secondary interface metrics** relates to **Multus CNI** and multiple network attachments on pods
+- **MTU changes** connect to the **cluster network operator** and **OVN-Kubernetes / OpenShift SDN** CNI plugins
+- **Connectivity verification** relates to **network diagnostics** and cluster health
+
+## Exam-Relevant Points
+- Know that SCTP is supported in OCP as a transport protocol (not just TCP/UDP)
+- PTP hardware support is an advanced networking feature in OCP — relevant for time-sensitive applications
+- MTU changes are a post-installation advanced networking operation
+- Secondary interfaces (via Multus) can expose metrics — understand that OCP supports multiple network interfaces per pod
+- Connectivity verification is a built-in cluster capability for network troubleshooting
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md

@@ -0,0 +1,11 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/legal-notice
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md
+---
+# En Documentation Openshift_Container_Platform 417 Html Advanced_Networking Legal
+
+**Date:** 2026-03-05
+**Time:** 13:17
+
+This is just a legal notice/copyright page — it contains no technical content relevant to OpenShift expertise or certification study. No summary worth creating here. Skip this page.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md

@@ -0,0 +1,92 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/network-bonding-considerations
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:17
+
+## Overview
+Network bonding (link aggregation) in OpenShift Container Platform combines multiple physical network interfaces into a single logical interface for fault tolerance and load balancing. OpenShift supports two bonding types: Open vSwitch (OVS) bonding and kernel bonding, each with different modes, capabilities, and configuration approaches.
+
+## Key Concepts
+- **Network bonding / link aggregation**: Combining multiple NICs into one logical interface for redundancy and/or load balancing
+- **OVS bonding**: Uses Open vSwitch to create bonds; MAC address management is centralized at the OVS bridge level; physical MAC addresses do not handle traffic directly
+- **OVS `active-backup` mode**: One active port handles traffic; standby ports monitor link status and take over on failure; all ports share the same MAC address
+- **OVS `balance-slb` mode**: Source load balancing across multiple physical interfaces without requiring switch-side negotiation; balances only across different MAC/VLAN combinations
+- **Limitation of balance-slb**: All OVN-Kubernetes pod traffic uses the same MAC and VLAN, so pod traffic **cannot** be load-balanced across interfaces — balance-slb is useful for VM workloads with different MACs
+- **OVS bridge architecture**: `br-ex` receives VM traffic → patch ports connect to `br-phy` → `br-phy` controls the SLB bond → physical NICs (e.g., `eno0`, `eno1`)
+- **Kernel bonding**: Built-in Linux kernel feature; bond interfaces exist **outside** the bridge data path; default if no OVS bonds are configured; less customizable than OVS bonding
+- **Kernel bonding `fail_over_mac`**: Only value `0` (`none`) is supported by Red Hat — all interfaces share the bond's MAC. Values `1` (`active`) and `2` (`follow`) are **not supported**
+
+## Commands and Syntax
+
+**NMState config for OVS balance-slb bond** (key fragment):
+```yaml
+- name: br-phy
+  type: ovs-bridge
+  state: up
+  bridge:
+    allow-extra-patch-ports: true
+    port:
+      - name: patch-phy-to-ex
+      - name: ovs-bond
+        link-aggregation:
+          mode: balance-slb
+          port:
+            - name: enp2s0
+            - name: enp3s0
+```
+
+**Base64-encode NMState config for MachineConfig embedding:**
+```bash
+base64 -w0 <nmstate_configuration>.yml
+```
+
+**MachineConfig manifest to apply bonding config:**
+```yaml
+apiVersion: machineconfiguration.openshift.io/v1
+kind: MachineConfig
+metadata:
+  labels:
+    machineconfiguration.openshift.io/role: master
+  name: 10-br-ex-master
+spec:
+  config:
+    ignition:
+      version: 3.2.0
+    storage:
+      files:
+      - contents:
+          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
+        mode: 0644
+        overwrite: true
+        path: /etc/nmstate/openshift/cluster.yml
+```
+
+**Procedure summary:**
+1. Define network interfaces in `install-config.yaml` under `networkConfig`
+2. Create NMState `NodeNetworkConfigurationPolicy` with bridge/bond definitions
+3. Base64-encode the NMState config
+4. Embed in `MachineConfig` manifests for `master` and/or `worker` roles
+5. Save manifests to `<installation_directory>/manifests`; MCO applies via rolling update
+
+## Relationships
+- **OVN-Kubernetes CNI plugin**: OVS bonding integrates natively with it
+- **NMState operator**: Used to define network interface configurations (`NodeNetworkConfigurationPolicy`)
+- **MachineConfig / MCO**: Delivers bonding configuration to nodes via Ignition
+- **NetworkAttachmentDefinition (NAD)**: VMs connect to localnet NADs to access physical networks through the bonded interfaces
+- **install-config.yaml**: Network interfaces must be defined here for bare-metal hosts
+- **br-ex bridge**: Central OVS bridge in OVN-Kubernetes networking; bonding extends its connectivity via `br-phy`
+
+## Exam-Relevant Points
+- OVS bonding supports two modes: **`active-backup`** and **`balance-slb`**
+- `balance-slb` does **not** load-balance OVN-Kubernetes pod traffic (same MAC/VLAN) — it benefits **VM workloads** with distinct MACs
+- Kernel bonding only supports `fail_over_mac=0` (`none`); values `1` and `2` are **unsupported**
+- Kernel bonding is the **default** when no OVS bonds are configured
+- OVS manages MAC addresses at the **bridge level**, not at individual physical interfaces
+- The NMState config is base64-encoded and delivered via **MachineConfig** at path `/etc/nmstate/openshift/cluster.yml`
+- The `br-phy` bridge acts as the **SLB bond controller**; patch ports connect `br-ex` to `br-phy`
+- MTU must be **manually set** on bond ports for `br-ex`
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md

@@ -0,0 +1,115 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/using-ptp-hardware
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:18
+
+## Overview
+This page covers Precision Time Protocol (PTP) hardware configuration in OpenShift Container Platform 4.17. It explains PTP concepts (grandmaster, boundary, and ordinary clocks), the linuxptp and gpsd software packages used for synchronization, how to install and configure the PTP Operator, and how to set up various clock configurations including grandmaster clocks with GNSS sources, boundary clocks, and dual/triple NIC setups for telco RAN deployments.
+
+## Key Concepts
+- **PTP (Precision Time Protocol)** provides sub-microsecond clock accuracy using hardware support, more accurate than NTP
+- **Three PTP clock types**: Grandmaster (authoritative time source, syncs to GNSS), Boundary (relays timing between upstream/downstream), Ordinary (single-port, source or destination)
+- **Best Master Clock (BMC) algorithm** automatically creates and updates the leader-follower clock hierarchy
+- **linuxptp package** provides `ts2phc`, `ptp4l`, `phc2sys`, and `pmc` daemons
+- **gpsd package** provides `ubxtool`, `gpspipe`, `gpsd` for GNSS clock synchronization
+- **PTP Operator** discovers PTP-capable devices, manages linuxptp services, and provides clock event notifications
+- PTP Operator works **only on bare-metal infrastructure**
+- **NTP/chronyd must be disabled** before enabling PTP (use MachineConfig CR)
+- GNSS timing supported **only with Intel E810 Westport Channel NICs**
+- **DPLL (Digital Phase-Locked Loop)** synchronizes clock phases between PTP nodes
+- **Leap seconds** can disrupt RAN networks if unhandled
+- **Fast event notifications** use pub-sub REST API via `cloud-event-proxy` sidecar over HTTP
+- **Dual-NIC** configurations: one NIC gets GNSS, second receives timing via SMA1 Tx/Rx connections
+- **3-card NIC** grandmaster clocks supported for D-RAN configurations
+- **Highly available boundary clocks** use dual NICs with A-BMCA algorithm (ITU-T G.8275.1) to maintain sync if one source fails
+- UDP hardware timestamping doesn't work with OVN-Kubernetes on `br-ex` interface (migration concern from openshift-sdn)
+
+## Commands and Syntax
+
+**Install PTP Operator (CLI):**
+```bash
+# Create namespace
+oc create -f ptp-namespace.yaml    # namespace: openshift-ptp
+
+# Create OperatorGroup
+oc create -f ptp-operatorgroup.yaml
+
+# Subscribe
+oc create -f ptp-sub.yaml          # channel: "stable", source: redhat-operators
+
+# Verify
+oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
+```
+
+**Discover PTP devices:**
+```bash
+oc get NodePtpDevice -n openshift-ptp -o yaml
+```
+
+**Key CRDs:**
+- `NodePtpDevice.ptp.openshift.io` — auto-created per node listing PTP-capable NICs
+- `PtpConfig` — configures linuxptp services (ptp4l, phc2sys, ts2phc)
+
+**PtpConfig CR structure (grandmaster example):**
+```yaml
+apiVersion: ptp.openshift.io/v1
+kind: PtpConfig
+metadata:
+  name: grandmaster
+  namespace: openshift-ptp
+spec:
+  profile:
+    - name: "grandmaster"
+      ptp4lOpts: "-2 --summary_interval -4"
+      phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_master -n 24
+      ptpSchedulingPolicy: SCHED_FIFO
+      ptpSchedulingPriority: 10
+      plugins:
+        e810:
+          enableDefaultConfig: false
+          settings:
+            LocalMaxHoldoverOffSet: 1500
+            LocalHoldoverTimeout: 14400
+            MaxInSpecOffset: 1500
+```
+
+**Namespace YAML:**
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: openshift-ptp
+  annotations:
+    workload.openshift.io/allowed: management
+  labels:
+    name: openshift-ptp
+    openshift.io/cluster-monitoring: "true"
+```
+
+## Relationships
+- **PTP Operator** → installed via OLM (Subscription, OperatorGroup in `openshift-ptp` namespace)
+- **MachineConfig** → used to disable chronyd before enabling PTP
+- **OVN-Kubernetes** → migration from openshift-sdn affects UDP hardware timestamping on br-ex
+- **Telco RAN / vRAN** → primary consumer of PTP; loss of sync can shut down radios
+- **cloud-event-proxy sidecar** → delivers PTP fast event notifications to applications
+- **Intel E810 NIC plugin** → hardware-specific configuration in PtpConfig CR
+- **ITU-T G.8275.1** → standard for A-BMCA algorithm used in HA boundary clock leader selection
+
+## Exam-Relevant Points
+- PTP provides **sub-microsecond** accuracy with hardware support; more accurate than NTP
+- PTP Operator runs **only on bare-metal** infrastructure
+- **NTP must be disabled** (chronyd via MachineConfig) before enabling PTP
+- GNSS sources require **Intel E810 Westport Channel NICs only**
+- PTP Operator namespace is `openshift-ptp` with label `openshift.io/cluster-monitoring: "true"`
+- The Operator auto-discovers PTP devices and creates `NodePtpDevice` CRs per node
+- Three clock types: **Grandmaster** (GNSS-synced), **Boundary** (multi-port relay), **Ordinary** (single port)
+- `ptp4l` implements boundary and ordinary clocks; `ts2phc` is used for grandmaster clock configs
+- `phc2sys` synchronizes the **system clock to the PHC** on the NIC
+- Fast event notifications use **pub-sub REST API** via `cloud-event-proxy` sidecar
+- Dual-NIC boundary clocks provide **high availability** — node maintains sync if one timing source fails
+- E810 NIC configuration uses a **plugin** stanza in the `PtpConfig` CR
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md

@@ -0,0 +1,93 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/verifying-connectivity-endpoint
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:18
+
+
+
+## Overview
+This page documents OpenShift's built-in network connectivity verification system. The Cluster Network Operator (CNO) runs a connectivity check controller that automatically performs TCP connection health checks between cluster resources every minute, storing results in `PodNetworkConnectivityCheck` objects in the `openshift-network-diagnostics` namespace.
+
+## Key Concepts
+- The **connectivity check controller** is managed by the CNO and runs connection tests every minute in parallel
+- **Health check source**: a single pod replica set (Deployment) that initiates connections to endpoints specified in `PodNetworkConnectivityCheck` objects
+- **Health check target**: a DaemonSet pod running on every node, listening for inbound health checks — enables testing connectivity to each node
+- Results are stored in `PodNetworkConnectivityCheck` custom resources (API group: `controlplane.operator.openshift.io/v1alpha1`)
+- All diagnostic resources live in the `openshift-network-diagnostics` namespace
+- Connectivity checks verify TCP reachability to: Kubernetes API server (service + endpoints), OpenShift API server (service + endpoints), load balancers (internal + external), and health check targets (service + endpoints on every node)
+- Diagnostics mode is configured via the `Network` CR (`config.openshift.io/v1`) named `cluster`, under `spec.networkDiagnostics`
+- Mode can be `"All"` (default), `"Disabled"`, or empty string (equivalent to `All`)
+- Pod placement for source/target pods is configurable via `nodeSelector` and `tolerations` under `sourcePlacement` and `targetPlacement`
+- Node labels must be applied **before** updating the network diagnostics configuration — labels applied after are ignored
+- Connection log reasons: `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError`
+- The `PodNetworkConnectivityCheck` status tracks: `conditions`, `failures`, `successes`, and `outages` (with start/end logs)
+
+## Commands and Syntax
+
+```bash
+# Edit connectivity check pod placement
+oc edit network.config.openshift.io cluster
+
+# Verify network diagnostics are enabled
+oc get network.config.openshift.io cluster -o yaml
+# Look for: status.conditions[].type: NetworkDiagnosticsAvailable with status: "True"
+
+# List all connectivity check objects
+oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
+
+# View detailed connectivity check results
+oc get podnetworkconnectivitycheck <name> -n openshift-network-diagnostics -o yaml
+
+# Verify source/target pod placement
+oc get pods -n openshift-network-diagnostics -o wide
+```
+
+**Network diagnostics configuration YAML:**
+```yaml
+apiVersion: config.openshift.io/v1
+kind: Network
+metadata:
+  name: cluster
+spec:
+  networkDiagnostics:
+    mode: "All"              # "All", "Disabled", or "" (empty = All)
+    sourcePlacement:
+      nodeSelector:
+        checkNodes: groupA
+      tolerations:
+      - key: myTaint
+        effect: NoSchedule
+        operator: Exists
+    targetPlacement:
+      nodeSelector:
+        checkNodes: groupB
+      tolerations:
+      - key: myOtherTaint
+        effect: NoExecute
+        operator: Exists
+```
+
+## Relationships
+- **Cluster Network Operator (CNO)**: manages the connectivity check controller and deploys source/target pods
+- **Network CR** (`config.openshift.io/v1`): central configuration point for network diagnostics settings; also relates to `network.operator.openshift.io` CR's `spec.disableNetworkDiagnostics` field (the `networkDiagnostics` stanza overrides it)
+- **Node scheduling**: ties into Kubernetes node selectors and tolerations for pod placement
+- **Troubleshooting workflows**: use connectivity checks to diagnose or eliminate network issues when investigating cluster problems
+- Source pod names follow the pattern `network-check-source-*`, targets follow `network-check-target-*`
+- Object naming convention: `<source>-to-<target>` where target includes identifiers like `kubernetes-apiserver-endpoint`, `load-balancer-api-external`, `openshift-apiserver-service-cluster`, etc.
+
+## Exam-Relevant Points
+- Connectivity checks run **every minute** in parallel
+- All objects are in the `openshift-network-diagnostics` namespace
+- The `PodNetworkConnectivityCheck` object name format is `<source>-to-<target>`
+- Diagnostics are configured on the `Network` CR named `cluster` (API: `config.openshift.io/v1`)
+- Three diagnostics modes: `All`, `Disabled`, empty string (= `All`)
+- Source pod is a **Deployment** (single replica); target pods are a **DaemonSet** (every node)
+- Node labels must exist **before** updating diagnostics configuration
+- To check if diagnostics are enabled, look for condition type `NetworkDiagnosticsAvailable` with status `"True"`
+- Connection log `reason` values: `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError`
+- Requires `cluster-admin` role to verify connectivity
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking.md

@@ -0,0 +1,36 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking
+source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:18
+
+## Overview
+The Advanced Networking section in OpenShift Container Platform 4.17 covers specialized networking topics beyond basic cluster networking, including MTU changes, connectivity verification, Stream Control Transmission Protocol (SCTP), Precision Time Protocol (PTP) hardware, and secondary interface metrics.
+
+## Key Concepts
+- **MTU changes** — Modifying Maximum Transmission Unit sizes for cluster networks
+- **Connectivity verification** — Tools/mechanisms to verify network connectivity within the cluster
+- **SCTP (Stream Control Transmission Protocol)** — A transport-layer protocol supported as an advanced networking feature in OCP
+- **PTP (Precision Time Protocol) hardware** — Hardware-based precision time synchronization for nodes
+- **Secondary interface metrics** — Monitoring and metrics collection for secondary (non-primary) network interfaces
+
+## Commands and Syntax
+No specific commands provided on this index page — each subtopic has its own detailed page.
+
+## Relationships
+- Builds on top of the base **Cluster Networking** configuration (SDN/OVN-Kubernetes)
+- **SCTP** relates to workloads requiring multi-streaming transport (e.g., telecom/5G)
+- **PTP** relates to **node configuration** and is critical for telco/RAN workloads requiring sub-microsecond time sync
+- **Secondary interface metrics** connects to **Multus CNI** and multiple network attachments
+- **MTU changes** affect both **cluster network operator** configuration and **node network state**
+
+## Exam-Relevant Points
+- Know that OCP supports SCTP as an advanced protocol option beyond TCP/UDP
+- PTP hardware support is a distinct advanced networking feature (important for telco use cases)
+- MTU changes are classified as an advanced networking operation (not a day-1 install config change)
+- Secondary interfaces can be monitored via dedicated metrics (ties into Multus/multiple networks)
+- Connectivity verification is a built-in capability for troubleshooting network issues
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md

@@ -0,0 +1,78 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/api-index
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:19
+
+## Overview
+
+This page provides the complete API index for OpenShift Container Platform 4.17, listing every API resource available in the platform alongside its API group. It serves as a reference catalog mapping resource kinds to their fully qualified API group versions, covering both upstream Kubernetes APIs and OpenShift-specific extensions.
+
+## Key Concepts
+
+- **API Groups** organize related resources under a common path (e.g., `apps/v1`, `config.openshift.io/v1`)
+- **Core APIs** (API group `v1`) include fundamental resources: Pod, Service, ConfigMap, Secret, Namespace, Node, PersistentVolume, PersistentVolumeClaim, Endpoints, Event, LimitRange, ResourceQuota, ServiceAccount
+- **OpenShift-specific API groups** extend Kubernetes with platform capabilities:
+  - `config.openshift.io/v1` — cluster-wide configuration (OAuth, Image, Network, Ingress, Infrastructure, Proxy, Scheduler, DNS, FeatureGate, ClusterVersion, ClusterOperator, APIServer, etc.)
+  - `operator.openshift.io/v1` — operator management resources
+  - `build.openshift.io/v1` — Build, BuildConfig, BuildLog, BuildRequest
+  - `route.openshift.io/v1` — Route (OpenShift's ingress mechanism)
+  - `image.openshift.io/v1` — ImageStream and related resources
+  - `apps.openshift.io/v1` — DeploymentConfig (legacy)
+  - `security.openshift.io/v1` — SecurityContextConstraints (SCC)
+  - `project.openshift.io/v1` — Project, ProjectRequest
+  - `quota.openshift.io/v1` — ClusterResourceQuota
+  - `oauth.openshift.io/v1` — OAuth tokens and clients
+  - `user.openshift.io/v1` — User, Group, Identity
+  - `template.openshift.io/v1` — Template, TemplateInstance
+- **Some resources exist in multiple API groups** (e.g., ClusterRole exists in both `authorization.openshift.io/v1` and `rbac.authorization.k8s.io/v1`; DNS in both `config.openshift.io/v1` and `operator.openshift.io/v1`)
+- **OLM (Operator Lifecycle Manager) APIs** under `operators.coreos.com` — CatalogSource, ClusterServiceVersion, Subscription, InstallPlan, OperatorGroup, OperatorCondition, OLMConfig
+- **Monitoring APIs** — Prometheus, Alertmanager, PrometheusRule, ServiceMonitor, PodMonitor (under `monitoring.coreos.com/v1`); AlertingRule, AlertRelabelConfig (under `monitoring.openshift.io/v1`)
+- **Machine management APIs** under `machine.openshift.io` — Machine, MachineSet, MachineHealthCheck, ControlPlaneMachineSet
+- **Machine configuration APIs** under `machineconfiguration.openshift.io/v1` — MachineConfig, MachineConfigPool, KubeletConfig, ContainerRuntimeConfig
+- **OVN networking APIs** under `k8s.ovn.org/v1` — EgressFirewall, EgressIP, EgressQoS, EgressService
+- **Bare metal APIs** under `metal3.io/v1alpha1` — BareMetalHost, FirmwareSchema, Provisioning, etc.
+- **Storage APIs** — CSIDriver, CSINode, StorageClass, VolumeSnapshot, VolumeSnapshotClass, VolumeSnapshotContent
+
+## Commands and Syntax
+
+No commands on this page — it is a pure reference index. To interact with these APIs:
+
+```bash
+# List all API resources on a cluster
+oc api-resources
+
+# Get resources from a specific API group
+oc get clusterversion          # config.openshift.io/v1
+oc get machineconfig           # machineconfiguration.openshift.io/v1
+oc get route -n <namespace>    # route.openshift.io/v1
+
+# Explain a resource's schema
+oc explain route.spec
+```
+
+## Relationships
+
+- **config.openshift.io/v1** resources define cluster-wide settings consumed by operators tracked via **ClusterOperator**
+- **operator.openshift.io/v1** resources configure individual operators that reconcile the config.openshift.io resources
+- **OLM resources** (CatalogSource → Subscription → InstallPlan → ClusterServiceVersion) form the operator installation lifecycle
+- **Machine API** chain: MachineSet → Machine → Node; MachineConfigPool → MachineConfig applies OS-level configuration
+- **RBAC** resources (Role, ClusterRole, RoleBinding, ClusterRoleBinding) in `rbac.authorization.k8s.io/v1` mirror OpenShift's `authorization.openshift.io/v1` equivalents
+- **Networking** spans multiple groups: NetworkPolicy (k8s), EgressFirewall/EgressIP (OVN), Route (OpenShift), Ingress (k8s), IngressController (operator)
+
+## Exam-Relevant Points
+
+- Know which API group a resource belongs to — especially `config.openshift.io/v1` vs `operator.openshift.io/v1`
+- **SecurityContextConstraints** is under `security.openshift.io/v1` (OpenShift-specific, not standard Kubernetes)
+- **Route** is `route.openshift.io/v1` — OpenShift's native ingress, distinct from Kubernetes Ingress (`networking.k8s.io/v1`)
+- **DeploymentConfig** (`apps.openshift.io/v1`) is OpenShift-specific and legacy; **Deployment** (`apps/v1`) is the standard Kubernetes resource
+- **ClusterVersion** (`config.openshift.io/v1`) tracks the cluster's current and desired version — key for upgrades
+- **ClusterOperator** (`config.openshift.io/v1`) reports operator status — essential for troubleshooting
+- Core v1 resources (Pod, Service, ConfigMap, Secret, Namespace, Node, PV, PVC) have no API group prefix
+- **ImageStream** (`image.openshift.io/v1`) is OpenShift-specific for image management
+- **MachineConfigPool** and **MachineConfig** are under `machineconfiguration.openshift.io/v1` — critical for node configuration
+- **Project** vs **Namespace**: Project (`project.openshift.io/v1`) wraps Namespace (`v1`) with additional policy
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md

@@ -0,0 +1,48 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/compatibility-guidelines
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:19
+
+## Overview
+This page defines Red Hat's API compatibility guidelines for OpenShift Container Platform, covering how APIs are maintained across releases, what exceptions exist, and key terminology around release types and support tiers. It is essential reading for understanding what is and isn't guaranteed to remain stable between OCP versions.
+
+## Key Concepts
+
+- **Forward compatibility only**: Applications built for OCP 4.14 are not guaranteed to work on 4.13 — they must run on an environment as new or newer than the one they target.
+- **No direct etcd access**: All etcd operations must go through the API server or documented backup/restore procedures.
+- **`unsupported<FieldName>` prefix**: API fields with this prefix have zero compatibility guarantees across or within releases.
+- **Undocumented annotations**: Usage of annotations not explicitly mentioned in product docs is not assured across minor releases.
+- **RHCOS filesystem modifications**: Not preserved across minor releases unless made through a supported Operator (MCO, Node Tuning Operator).
+- **Cloud infrastructure modifications**: Not preserved unless made through a public product interface or documented supported configuration.
+- **Functional defaults may differ**: A fresh install of version X may have different defaults than a cluster upgraded to version X from an earlier version.
+- **API availability varies by topology**: Not all APIs are present in every installation topology (e.g., some topologies may restrict or omit certain APIs).
+- **z-stream releases never break API/AOE compatibility** except for critical security issues.
+- **EUS deprecation policy**: Deprecation is defined across minor releases, not EUS releases — EUS users may need to respond to deprecations when migrating between EUS versions by upgrading through each minor release sequentially.
+
+## Commands and Syntax
+
+No specific CLI commands on this page. The guidelines are policy-oriented, not procedural.
+
+## Relationships
+
+- **Machine Config Operator / Node Tuning Operator**: The supported interfaces for host OS modifications on RHCOS.
+- **RHEL compatibility guidelines**: OCP inherits and extends RHEL ABI compatibility principles (avoid `proc`/`sys`/`debug` filesystems, `ioctls`, direct `cgroups` interaction).
+- **API tiers**: References a tiered support model (defined elsewhere) that determines compatibility guarantees per API.
+- **Cloud provider integrations**: Dynamic volume provisioning, service load balancers, pod workload identity, and compute management are integration points subject to both OCP and cloud vendor compatibility windows.
+- **Developer Preview vs Technology Preview**: Two distinct pre-GA support levels — Developer Preview is unsupported and opt-in (may render cluster unsupportable); Technology Preview is partially supported but not production-ready.
+
+## Exam-Relevant Points
+
+- **Release versioning**: In `4.13.2` → 4 = major, 13 = minor, 2 = z-stream.
+- **z-stream = no breaking changes** (except critical security).
+- **AOE definition**: Containerized environment sharing the host kernel but isolated from host OS libraries/binaries. Does not include CNI plugin selection or admission hooks.
+- **EUS**: Extended User Support — extended support window for critical fixes on select minor releases; upgrade path requires sequential minor release adoption.
+- **Developer Preview**: Opt-in, unsupported, may render cluster unsupportable, can be removed at any time.
+- **Technology Preview**: Opt-in, not fully supported, not for production use, provides early access to upcoming features.
+- **Never depend on**: specific kernel versions, `proc`/`sys`/`debug` filesystems, direct `cgroups` interaction, `ioctls`, `unsupported`-prefixed fields, undocumented annotations, or system package config files.
+- **Always use**: published client libraries, Operator-provided APIs over direct config file modification, API server for all cluster state access.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md

@@ -0,0 +1,87 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/editing-kubelet-log-level-verbosity
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:20
+
+## Overview
+This page covers how to modify kubelet log verbosity levels in OpenShift Container Platform for troubleshooting node issues. It describes both temporary (one-time) and persistent methods for changing log levels, explains the meaning of each verbosity level, and provides commands for gathering kubelet logs from cluster nodes.
+
+## Key Concepts
+- **Kubelet log verbosity** is controlled via the `KUBELET_LOG_LEVEL` environment variable, configured through systemd drop-in files
+- The **default log level is 2**, which provides useful steady-state information and is the recommended default
+- Log levels **0–4 are debug-level**; levels **5–8 are trace-level**
+- Systemd drop-in files use numeric ordering — `30-logging.conf` overrides `20-logging.conf`
+- **One-time changes** are made directly on the node and don't survive reboots
+- **Persistent changes** use a `MachineConfig` object, which survives reboots and is managed by the Machine Config Operator
+
+## Commands and Syntax
+
+**One-time kubelet log level change (via debug node):**
+```bash
+oc debug node/<node>
+chroot /host
+systemctl cat kubelet                    # check current log level
+echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf
+systemctl daemon-reload
+systemctl restart kubelet
+```
+
+**Revert one-time change:**
+```bash
+rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf
+systemctl daemon-reload
+systemctl restart kubelet
+```
+
+**Persistent log level via MachineConfig:**
+```yaml
+apiVersion: machineconfiguration.openshift.io/v1
+kind: MachineConfig
+metadata:
+  labels:
+    machineconfiguration.openshift.io/role: master
+  name: 99-master-kubelet-loglevel
+spec:
+  config:
+    ignition:
+      version: 3.2.0
+    systemd:
+      units:
+        - name: kubelet.service
+          enabled: true
+          dropins:
+            - name: 30-logging.conf
+              contents: |
+                [Service]
+                Environment="KUBELET_LOG_LEVEL=2"
+```
+
+**Gathering logs:**
+```bash
+oc adm node-logs --role master -u kubelet    # master kubelet logs
+oc adm node-logs --role worker -u kubelet    # worker kubelet logs
+journalctl -b -f -u kubelet.service          # from inside the node
+sudo tail -f /var/log/containers/*           # container logs on node
+# All nodes at once:
+for n in $(oc get node --no-headers | awk '{print $1}'); do oc adm node-logs $n | gzip > $n.log.gz; done
+```
+
+## Relationships
+- **MachineConfig / Machine Config Operator (MCO)**: Persistent log level changes are applied through MachineConfig objects, which the MCO rolls out to nodes
+- **`oc debug node`**: The primary mechanism for accessing node internals for one-time troubleshooting
+- **systemd**: Kubelet runs as a systemd service; log level is configured via systemd drop-in files
+- **`oc adm node-logs`**: The cluster-external way to retrieve node-level service logs without SSH
+- **Ignition**: MachineConfig uses Ignition spec (v3.2.0) to define systemd unit drop-ins
+
+## Exam-Relevant Points
+- The default kubelet log level is **2** (`KUBELET_LOG_LEVEL=2`)
+- Log levels 0–4 = debug; 5–8 = trace
+- One-time log changes go in `/etc/systemd/system/kubelet.service.d/30-logging.conf` and require `systemctl daemon-reload && systemctl restart kubelet`
+- `oc adm node-logs --role <role> -u kubelet` gathers kubelet logs by node role without needing SSH
+- Persistent changes require a **MachineConfig** with the `machineconfiguration.openshift.io/role` label targeting the correct pool (master/worker)
+- `oc debug node/<node>` followed by `chroot /host` is the standard way to access a node's filesystem for troubleshooting
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-index.md

@@ -0,0 +1,32 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/index
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:20
+
+## Overview
+This is the landing page for the OpenShift Container Platform 4.17 API overview documentation. It serves as an entry point to the API reference material but contains minimal substantive content itself — it primarily links to the detailed API documentation sections.
+
+## Key Concepts
+- OpenShift Container Platform exposes its functionality through a comprehensive **REST API**
+- The API documentation covers OCP version **4.17** (with docs available across versions 3.0–4.21)
+- The API overview is maintained by the **Red Hat OpenShift Documentation Team**
+- Documentation is available in **multi-page**, **single-page**, and **PDF** formats
+
+## Commands and Syntax
+No commands or syntax are provided on this landing page. The actual API endpoints and usage are documented in sub-pages.
+
+## Relationships
+- **Kubernetes API**: OCP's API extends the upstream Kubernetes API with additional resources (Routes, DeploymentConfigs, BuildConfigs, etc.)
+- **oc CLI**: The `oc` command-line tool is the primary client for interacting with the OCP API
+- **OAuth/Authentication**: API access is governed by OCP's authentication and authorization mechanisms
+- **Operators**: Many OCP APIs are provided by Operators via Custom Resource Definitions (CRDs)
+
+## Exam-Relevant Points
+- OpenShift Container Platform is **API-driven** — all cluster operations can be performed via the API
+- The API is versioned and version-specific documentation exists for each OCP release
+- Understanding the API structure is foundational for topics like automation, CI/CD integration, and custom controller development
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md

@@ -0,0 +1,51 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/understanding-api-support-tiers
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:20
+
+## Overview
+This page defines the API compatibility tier system used by Red Hat OpenShift Container Platform. It classifies all commercially supported APIs, components, and features into four tiers (1–4) with decreasing stability guarantees, maps specific API groups to those tiers, and describes the deprecation policy governing how and when APIs can be removed.
+
+## Key Concepts
+- **API Tier 1**: Stable within a major release. Cannot be removed until a subsequent major release. Highest compatibility guarantee.
+- **API Tier 2**: Stable for at least 9 months or 3 minor releases from deprecation announcement, whichever is longer.
+- **API Tier 3**: Component-specific lifetime; minor-to-minor compatibility is not guaranteed. Default tier for API groups without explicit assignment. Operators from OperatorHub fall here.
+- **API Tier 4**: No compatibility guaranteed. Can change at any time. `v1alpha1` APIs default to this tier. Internal CRDs used by Operators should be annotated as tier 4 via `operators.operatorframework.io/internal-objects`.
+- **AOE (Application Operating Environment)**: The runtime environment compatibility level, governed by the same tier system.
+- Cloud-specific and hardware-specific integrations have no compatibility beyond what the vendor provides.
+- Developers should only depend on formally documented API behavior, not implementation-specific behavior or bugs.
+- Deprecation policy covers: REST resources (API objects), fields, annotations (excluding version-specific qualifiers), and enumerated/constant values.
+- Tier 1 rules: elements removed only by incrementing group version; round-trip between versions without info loss; cannot deprecate until an equally stable version exists.
+
+## Commands and Syntax
+No CLI commands on this page, but relevant annotations and conventions:
+- `operators.operatorframework.io/internal-objects` — CSV annotation marking CRDs as internal/tier 4
+- API group suffixes determine governance:
+  - `*.k8s.io` or `version.<name>` — Kubernetes deprecation policy
+  - `*.openshift.io` — OpenShift deprecation policy
+  - `monitoring.coreos.com` — All versions (including alpha/beta) are Tier 1
+  - `operators.coreos.com` — All versions (including alpha) are Tier 1
+
+## Relationships
+- **Kubernetes deprecation policy**: OCP inherits and normalizes upstream Kubernetes API versioning conventions (v1→Tier 1, v1beta1→Tier 2, v1alpha1→Tier 4).
+- **Operator Lifecycle Manager (OLM)**: APIs under `operators.coreos.com` are all Tier 1 regardless of version suffix.
+- **OperatorHub / Operators**: Components delivered via OperatorHub are Tier 3 by default — developers must consult per-component compatibility docs.
+- **CLI deprecation**: CLI elements inherit API tier of their underlying API, defaulting to Tier 1 for GA, Tier 3 for Tech Preview, Tier 4 for Developer Preview.
+- **Component removal**: Governed by the highest-tier API the component exposes.
+
+## Exam-Relevant Points
+- **Tier 1 = stable within major release; Tier 2 = 9 months or 3 releases; Tier 3 = component-specific; Tier 4 = no guarantee.**
+- `v1alpha1` APIs default to **Tier 4** (no compatibility), except for `monitoring.coreos.com` and `operators.coreos.com` where alpha is **Tier 1**.
+- Any API group without an explicit tier assignment defaults to **Tier 3**.
+- `route.openshift.io/v1`, `config.openshift.io/v1`, `oauth.openshift.io/v1` are all **Tier 1**.
+- `console.openshift.io/v1` is notably **Tier 2**, not Tier 1.
+- `security.openshift.io/v1` is Tier 1 **except** `RangeAllocation` (Tier 4) and `*Reviews` (Tier 2).
+- GA CLI flags/commands are **Tier 1**; Tech Preview CLI elements are **Tier 3**; Developer Preview are **Tier 4**.
+- Tier 1 APIs must round-trip between versions without information loss.
+- Component deprecation timeline is dictated by its **highest-tier** API.
+- This guidance does **not** cover layered OCP offerings.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview.md

@@ -0,0 +1,33 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview
+source: sources/en-documentation-openshift_container_platform-417-html-api_overview.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:21
+
+## Overview
+This is the landing page for the OpenShift Container Platform 4.17 API overview documentation. It serves as an entry point to API reference material for OCP, providing navigation to detailed API documentation. The page itself contains minimal substantive content beyond framing.
+
+## Key Concepts
+- OpenShift Container Platform exposes a comprehensive **API** that underpins all platform operations
+- The API documentation is versioned per OCP release (this covers **4.17**)
+- API docs are available in multi-page, single-page, and PDF formats
+- The API is the foundational interface through which all OCP resources (pods, deployments, routes, builds, etc.) are managed
+
+## Commands and Syntax
+No specific commands or syntax are provided on this landing page.
+
+## Relationships
+- **Kubernetes API**: OCP's API extends the upstream Kubernetes API with additional resource types (Routes, BuildConfigs, DeploymentConfigs, ImageStreams, etc.)
+- **oc CLI**: The `oc` command-line tool interacts with these APIs
+- **Custom Resources (CRDs)**: Operators extend the API surface with custom resource definitions
+- **RBAC**: API access is governed by role-based access control policies
+
+## Exam-Relevant Points
+- OpenShift Container Platform builds on and extends the Kubernetes API
+- Every `oc` command corresponds to an underlying API call
+- Understanding the API group structure (e.g., `apps.openshift.io`, `route.openshift.io`, `build.openshift.io`) is important for RBAC and resource management
+- API versions follow the OCP release versioning (docs are version-specific)
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md

@@ -0,0 +1,47 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/about-the-multicluster-engine-for-kubernetes-operator
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:21
+
+## Overview
+The multicluster engine for Kubernetes Operator addresses the challenge of managing the lifecycle of multiple Kubernetes clusters at scale. It provides full lifecycle management for OpenShift Container Platform clusters and partial lifecycle management for other Kubernetes distributions. It is available either as a standalone operator included with OpenShift Container Platform / OpenShift Kubernetes Engine subscriptions, or as part of Red Hat Advanced Cluster Management for Kubernetes (RHACM).
+
+## Key Concepts
+- **Multicluster engine Operator**: An operator for managing the lifecycle of a fleet of Kubernetes clusters at scale
+- **Two delivery modes**: Standalone operator (included with OCP subscription) or as part of RHACM
+- **Delivered separately** from the core OCP payload — must be installed after deploying OCP
+- **Full lifecycle management** for managed OCP clusters; **partial lifecycle** for other Kubernetes distributions
+- **RHACM relationship**: Multicluster engine is an integral part of RHACM and is enabled by default when RHACM is installed
+
+## Commands and Syntax
+No specific CLI commands are documented on this page. Installation is referenced via the RHACM documentation: "Installing and upgrading multicluster engine operator."
+
+## Key Capabilities (when enabled on OCP)
+- **Hosted control planes** (based on HyperShift): Operate OCP clusters in a hyperscale manner with centralized hosted control planes
+- **Hive**: Provisions self-managed OCP clusters to the hub and performs initial cluster configuration
+- **klusterlet agent**: Registers managed clusters to the hub
+- **Infrastructure Operator**: Manages Assisted Service deployment for on-premise bare metal and vSphere OCP installations (including single-node OpenShift). Includes **GitOps Zero Touch Provisioning (ZTP)** for fully automated bare metal and vSphere provisioning using GitOps workflows
+- **Open cluster management**: Provides resources for managing Kubernetes clusters
+
+## Relationships
+- **OpenShift Container Platform**: Multicluster engine runs on top of OCP and extends it with fleet management
+- **Red Hat Advanced Cluster Management (RHACM)**: Multicluster engine is a subset of RHACM; RHACM provides additional capabilities beyond what multicluster engine alone offers
+- **HyperShift**: The upstream project that hosted control planes are based on
+- **Assisted Service / Infrastructure Operator**: Ties into bare metal and vSphere provisioning workflows
+- **GitOps ZTP**: Integrates with the Infrastructure Operator for automated edge/bare metal deployments
+- **Hive**: The provisioning component for self-managed clusters
+
+## Exam-Relevant Points
+- Multicluster engine is **included with OCP subscription** but **delivered separately** from the core payload — it must be explicitly installed
+- It provides **full lifecycle** for OCP clusters but only **partial lifecycle** for non-OCP Kubernetes
+- **Hosted control planes** (HyperShift-based) enable hyperscale cluster operations
+- **Hive** provisions self-managed clusters; **klusterlet** registers managed clusters to the hub
+- **Infrastructure Operator** handles bare metal and vSphere installations, including single-node OpenShift
+- **GitOps ZTP** automates bare metal and vSphere cluster creation with GitOps workflows
+- If you need capabilities **beyond** what multicluster engine provides, use **RHACM**
+- Multicluster engine is **enabled by default** in RHACM
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md

@@ -0,0 +1,79 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/admission-plug-ins
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:21
+
+## Overview
+Admission plugins in OpenShift Container Platform intercept API requests after authentication and authorization to enforce policies such as security, resource limits, and configuration requirements. They run sequentially in an admission chain, and the chain can be extended dynamically using webhook admission plugins that call external webhook servers.
+
+## Key Concepts
+- **Admission chain**: Plugins run in sequence; if any plugin rejects a request, the entire chain aborts and returns an error
+- **Two types of webhook admission plugins**: mutating (runs first, can modify resources and validate) and validating (runs after mutating, validates only)
+- **Default plugins**: OCP 4.17 ships with a large set of default validating and mutating plugins that are required for proper cluster functioning
+- **Webhook parallelism**: When webhooks are called, they are called in parallel; all must approve or the request is denied (only the first denial reason is returned)
+- **Failure policy**: Webhooks can be configured with `Fail` (deny on error) or `Ignore` (accept on error); `Ignore` can cause unpredictable behavior
+- **TLS required**: Communication between webhook admission plugin and webhook server must use TLS
+- **Maximum webhook timeout**: 13 seconds (cannot be changed)
+- **Highly privileged projects** (`default`, `kube-public`, `kube-system`, `openshift`, `openshift-infra`, `openshift-node`, and projects with `openshift.io/run-level` label `0` or `1`) bypass admission plugins like pod security admission, SCCs, cluster resource quotas, and image reference resolution
+
+## Commands and Syntax
+
+**Webhook configuration resources:**
+- `MutatingWebhookConfiguration` (kind) — `admissionregistration.k8s.io/v1beta1`
+- `ValidatingWebhookConfiguration` (kind) — `admissionregistration.k8s.io/v1beta1`
+
+**Key fields in webhook config:**
+```yaml
+webhooks:
+- name: <webhook_name>
+  clientConfig:
+    service:
+      namespace: default
+      name: kubernetes
+      path: <webhook_url>
+    caBundle: <ca_signing_certificate>   # PEM-encoded, base64
+  rules:
+  - operations: [create, update, delete, connect]
+    apiGroups: [""]
+    apiVersions: ["*"]
+    resources: [<resource>]
+  failurePolicy: Fail | Ignore
+  sideEffects: None
+```
+
+**Deploying a dynamic webhook (high-level procedure):**
+1. Build and publish webhook server container image
+2. Create CA key/cert, sign webhook server's CSR
+3. `oc new-project my-webhook-namespace`
+4. Define and apply RBAC rules: `oc auth reconcile -f rbac.yaml`
+5. Deploy webhook as DaemonSet: `oc apply -f webhook-daemonset.yaml`
+6. Create TLS secret: `oc apply -f webhook-secret.yaml`
+7. Create ServiceAccount and Service: `oc apply -f webhook-service.yaml`
+8. Register as aggregated API server via `APIService` resource
+9. Create the `ValidatingWebhookConfiguration` or `MutatingWebhookConfiguration`
+
+## Relationships
+- **Security Context Constraints (SCCs)**: `security.openshift.io/SecurityContextConstraint` is a default admission plugin
+- **Resource Quotas**: Both `ResourceQuota` and `quota.openshift.io/ClusterResourceQuota` are default validating plugins
+- **RBAC**: Webhook servers use RBAC for access control; `system:auth-delegator` ClusterRole is used for authentication delegation
+- **API Server**: Admission plugins are part of the API server request processing pipeline (after authn/authz, before persistence)
+- **Pod Security**: Pod security admission does not work in highly privileged projects
+- **Aggregated API Servers**: Webhook servers are typically configured as aggregated API servers for internal credential use and RBAC integration
+- **SR-IOV, Scheduling, Networking**: Specific default plugins handle network policy, node selectors, tolerations, and ingress
+
+## Exam-Relevant Points
+- Mutating admission plugins run **before** validating admission plugins
+- If **any** plugin in the admission chain rejects, the **entire chain** is aborted
+- The maximum webhook timeout is **13 seconds** and **cannot be changed**
+- `failurePolicy: Ignore` unconditionally accepts requests when the webhook is unavailable — this is risky
+- Default projects (`default`, `kube-public`, `kube-system`, `openshift`, `openshift-infra`, `openshift-node`) are highly privileged and **bypass** admission plugin functionality like SCCs, pod security admission, and cluster resource quotas
+- Webhook communication **must** use TLS
+- When multiple webhooks deny a request, only the **first denial reason** is returned
+- Common webhook use cases: namespace reservation, SR-IOV network resource limiting, toleration definitions, pod priority class validation
+- The two webhook configuration resource kinds are `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`
+- Webhooks are called **in parallel**, not sequentially (the overall mutating/validating phases are sequential, but webhooks within each phase run in parallel)
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-architecture.md

@@ -0,0 +1,79 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/architecture-rhcos
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-architecture.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:22
+
+## Overview
+
+Red Hat Enterprise Linux CoreOS (RHCOS) is the immutable, container-optimized operating system that underpins OpenShift Container Platform 4.x. It is the **only supported OS for control plane nodes** and the default for worker nodes (though RHEL can be used for workers). RHCOS is configured at provisioning time via Ignition config files, and all subsequent changes are managed remotely through the Machine Config Operator (MCO), enforcing a "controlled immutability" model.
+
+## Key Concepts
+
+- **RHCOS is based on RHEL** — same kernel, RPM packages, systemd init system, and security standards.
+- **Controlled immutability** — the OS is mostly read-only; configuration is managed by the cluster, not by admins logging into nodes.
+- **CRI-O is the only container engine** in OpenShift clusters (not Docker). It can use `runC` or `crun` as the container runtime.
+- **Container tools**: `podman` (run/manage containers), `skopeo` (copy/sign images), `crictl` (CRI-O debugging) replace the Docker CLI. Direct use on RHCOS is discouraged except for debugging.
+- **rpm-ostree** delivers transactional, atomic OS upgrades via container images. Rollback is a single reboot.
+- **bootupd** handles firmware and bootloader updates (UEFI and legacy BIOS) on x86_64, ppc64le, aarch64.
+- **Filesystem layout**:
+  - `/usr` — read-only (OS binaries/libraries)
+  - `/etc`, `/boot`, `/var` — writable, but only intended to be changed by the MCO
+  - `/var/lib/containers` — container image graph storage
+- **Ignition** is the first-boot provisioning utility; it runs from initramfs, configures disks/files/users, and the machine is ready without a reboot.
+- **Ignition is declarative** — partial configurations are not possible; if setup fails, the machine is not added to the cluster.
+- **Ignition supports RAID but not LVM**.
+- Ignition config files contain certificates that **expire after 24 hours**; use them within **12 hours** of generation.
+- **Default user**: `core` (SSH key injected via Ignition).
+
+## Commands and Syntax
+
+```bash
+# Generate Ignition config files
+openshift-install create ignition-configs --dir $HOME/testconfig
+# Produces: bootstrap.ign, master.ign, worker.ign
+
+# View Ignition config contents
+cat $HOME/testconfig/bootstrap.ign | jq
+
+# Decode base64-encoded file content from Ignition
+echo <base64-string> | base64 --decode
+
+# List machine config pools
+oc get machineconfigpools
+
+# List all machine configs
+oc get machineconfig
+
+# See files managed by a specific machine config
+oc describe machineconfigs 01-worker-container-runtime | grep Path:
+```
+
+## Relationships
+
+- **Machine Config Operator (MCO)** — manages all post-installation OS configuration and upgrades for RHCOS nodes; applies MachineConfig objects.
+- **MachineConfigPool** — groups nodes (master/worker) and their rendered machine configs.
+- **Ignition** — handles first-boot configuration; MCO takes over afterward using the same Ignition config spec format.
+- **install-config.yaml** — feeds into `openshift-install` which generates Ignition configs.
+- **Day-1 vs Day-2 customizations** — Day-1 via Ignition/manifests during install; Day-2 via MachineConfig CRs or Operator custom resources after cluster is running.
+- **Bootstrap machine** — serves Ignition configs to control plane nodes; workers get configs from control plane nodes (via API endpoint on port 22623).
+- **ContainerRuntimeConfig CR** — used to switch between `runC` and `crun`.
+
+## Exam-Relevant Points
+
+- RHCOS is **mandatory for control plane nodes**; workers can optionally run RHEL.
+- The container engine is **CRI-O** (not Docker) — this is frequently tested.
+- Ignition runs **only on first boot** from initramfs; subsequent changes go through the MCO.
+- Ignition is **declarative, not procedural** — machines cannot be partially configured.
+- Ignition config certificates expire after **24 hours**; best practice is to use within **12 hours**.
+- Machine configs are applied in **lexicographic order** (00* through 99*); last file wins for conflicts.
+- The rendered MachineConfig is a **union** of all input MachineConfig objects for a pool.
+- `/usr` is **read-only**; `/etc`, `/boot`, `/var` are writable but MCO-managed.
+- Worker Ignition configs reference the bootstrap/control plane via `https://api.<cluster>:22623/config/worker`.
+- Prefer **Kubernetes workload objects** (DaemonSet, Deployment) over node-level customization to reduce upgrade risk.
+- Day-1 customization examples: kernel arguments, disk encryption (FIPS), kernel modules, chronyd settings.
+- `rpm-ostree` upgrades are **atomic** with single-reboot rollback capability.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md

@@ -0,0 +1,70 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/control-plane
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:22
+
+## Overview
+The OpenShift Container Platform control plane consists of control plane (master) machines that manage the cluster and its worker nodes. It relies on machine config pools (MCPs) for node configuration management, Operators (both cluster and add-on) for managing cluster functions, and etcd as the persistent data store. The Cluster Version Operator (CVO) and Machine Config Operator coordinate upgrades across the cluster.
+
+## Key Concepts
+
+- **Control plane machines** manage workloads on compute/worker machines; cluster upgrades are driven by the CVO, MCO, and individual Operators
+- **Machine Config Pools (MCPs)** group machines by role for unified configuration management; two defaults: `master` and `worker`
+- **Custom MCPs** inherit from the worker pool; they can target changes to specific node groups (e.g., `infra`) while still receiving worker pool changes
+- **A node can only belong to one MCP** — custom pools take priority over the worker pool based on node labels
+- **Configuration drift** occurs when a node's actual config doesn't match its MCP's machine config; the MCD detects this and marks the node `degraded`
+- **Degraded nodes** are online and operational but cannot be updated
+- **Infra nodes** labeled with the `infra` role running only infra workloads do **not** count toward subscription charges (must also use taints to prevent user workload scheduling)
+- **Exactly three control plane nodes** are required for production; bare metal clusters can scale up to five
+- **Control plane and node versions must match** (temporary skew allowed during upgrades)
+- **kubelet must not be newer than kube-apiserver**; can be up to 1 minor version older (odd OCP versions) or 2 minor versions older (even OCP versions)
+- **CRI-O** is the container engine (not Docker); both CRI-O and kubelet run as **systemd services** directly on the host
+- **Worker node services**: CRI-O, kubelet, service proxy, runC/crun container runtime
+- **Kubernetes control plane components**: API server, etcd, controller manager, scheduler
+- **OpenShift-specific control plane components**: OpenShift API server, OpenShift controller manager, OpenShift OAuth API server, OpenShift OAuth server
+- **Two Operator management systems**: Cluster Operators (managed by CVO, installed by default) and add-on Operators (managed by OLM, optional)
+- **OLM does not manage cluster Operators** — those are managed by the CVO
+- **OperatorHub** catalog sources: Red Hat Operators, certified Operators, community Operators, and custom catalogs
+- **etcd** is a consistent, distributed key-value store; the primary data store for Kubernetes; requires fast, low-latency I/O
+
+## Commands and Syntax
+
+No direct CLI commands in this page, but key administrative references:
+
+- View Cluster Operators: **Administration → Cluster Settings** in the web console
+- `ClusterOperator` objects represent each cluster Operator
+- `installer-*` and `revision-pruner-*` pods run as root, writing to `/etc/kubernetes` in namespaces:
+  - `openshift-etcd`
+  - `openshift-kube-apiserver`
+  - `openshift-kube-controller-manager`
+  - `openshift-kube-scheduler`
+
+## Relationships
+
+- **MCO ↔ MCPs**: MCO manages MCPs and facilitates updates; MCD detects configuration drift
+- **CVO ↔ Cluster Operators**: CVO manages all default cluster Operators
+- **OLM ↔ Add-on Operators**: OLM manages optional Operators installed via OperatorHub
+- **etcd ↔ Control Plane**: etcd stores all cluster state; watched by controllers and schedulers
+- **Machine API ↔ Compute Machine Sets**: machine sets under `machine-api` namespace control compute machines (distinct from MCPs under MCO namespace)
+- **Control Plane Machine Sets**: manage control plane machines on supported cloud providers
+- **Operator SDK → Custom Operators → OLM**: developers author Operators, bundle them into custom catalogs
+
+## Exam-Relevant Points
+
+1. **Default MCPs are `master` and `worker`** — custom MCPs for control plane are not supported
+2. **Custom MCPs inherit from the worker pool** — non-inheriting custom pools are unsupported by the MCO
+3. **A node belongs to exactly one MCP** — custom pools take priority over worker pool
+4. **Infra nodes don't count toward subscriptions** if properly labeled and tainted
+5. **Removing `worker` label without a custom pool makes a node unmanaged** by the MCO
+6. **Three control plane nodes required for production** (up to five on bare metal)
+7. **kubelet version skew**: up to 1 minor version older for odd OCP releases, up to 2 for even releases
+8. **CRI-O is the container engine**, not Docker — runs as a systemd service
+9. **Two Operator systems**: CVO for cluster Operators, OLM for add-on Operators — they are separate
+10. **etcd requires fast, low-latency I/O** due to high-frequency small writes
+11. **Configuration drift** → node marked `degraded` → online but cannot be updated
+12. **MCO applies pool updates independently** — pools update in parallel with each other
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-index.md

@@ -0,0 +1,33 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/index
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:23
+
+## Overview
+This is the top-level landing page for the OpenShift Container Platform 4.17 Architecture documentation. It serves as an entry point to detailed architectural topics covering platform and application architecture in OpenShift Container Platform.
+
+## Key Concepts
+- OpenShift Container Platform 4.17 has a dedicated **Architecture** documentation section covering both **platform architecture** and **application architecture**
+- The architecture docs are available across many OCP versions (from 3.0 through 4.21), indicating architecture is a foundational documentation area
+- This is a hub page — the substantive content lives in sub-pages beneath it
+
+## Commands and Syntax
+None on this page (it is a navigation/landing page).
+
+## Relationships
+- Parent topic for all architecture sub-pages (likely covering control plane, worker nodes, networking architecture, storage architecture, etc.)
+- Connects to the broader OCP 4.17 documentation set
+- Architecture understanding is foundational to installation, operations, networking, and security topics
+
+## Exam-Relevant Points
+- OpenShift Container Platform distinguishes between **platform architecture** (infrastructure, control plane, operators) and **application architecture** (how workloads are structured and deployed)
+- The current version documented here is **4.17** — version awareness matters for exam contexts
+
+---
+
+*Note: This source page is a table-of-contents landing page with minimal substantive content. The real architectural detail will be in the child pages beneath this section.*
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md

@@ -0,0 +1,49 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/ocm-overview-ocp
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:23
+
+## Overview
+Red Hat OpenShift Cluster Manager (OCM) is a managed service providing a single dashboard to install, modify, operate, and upgrade OpenShift clusters. It supports OpenShift Container Platform (self-managed), Red Hat OpenShift Service on AWS (ROSA), and OpenShift Dedicated clusters, offering lifecycle management from installation through ongoing operations.
+
+## Key Concepts
+- **OpenShift Cluster Manager (OCM)** — centralized web-based management console for all OpenShift clusters in an organization
+- Accessible at `console.redhat.com/openshift` with a Red Hat account that belongs to an OpenShift organization
+- Supports three cluster types: OCP (self-installed), ROSA, and OpenShift Dedicated
+- **Cluster ID** — unique identifier used for CLI commands against the cluster
+- **Domain prefix** — defaults to the cluster name, used throughout the cluster
+- **Delete Protection** — can be enabled/disabled per cluster to prevent accidental deletion
+- **Insights Advisor** — leverages Remote Health functionality to identify risks to security, performance, availability, and stability
+- **Machine pools** — groupings of compute nodes that can be created/edited if quota is available
+- **Update strategy** — can be automatic (scheduled day/time) or manual
+
+## Commands and Syntax
+No CLI commands are described on this page. All interactions are through the web UI at:
+```
+https://console.redhat.com/openshift
+```
+
+## Relationships
+- **Insights Advisor** connects to the Remote Health / Telemetry subsystem of OCP
+- **Access control tab** relates to identity providers and RBAC — cluster owners can grant "Cluster Editor" roles
+- **Machine pools** relate to cluster scaling, node labels, taints, and AWS security groups
+- **OIDC configuration** ties into authentication and identity management
+- **Networking tab** relates to cluster network configuration (address/prefix)
+- OCM is the management layer above the individual cluster — it does not replace the in-cluster web console but complements it (the "Open console" action launches the cluster's own web console)
+
+## Exam-Relevant Points
+- OCM URL: `console.redhat.com/openshift`
+- Prerequisites: Red Hat account in an OpenShift organization; organization must have specified quota for cluster creation
+- Key cluster tabs: Overview, Access control, Add-ons, Networking, Insights Advisor, Machine pools, Support, Settings
+- The **Cluster ID** is used when issuing CLI commands to the cluster
+- Update strategy options: automatic (specific day/time) or manual
+- Cluster owners can grant the **Cluster Editor** role to other users via the Access control tab
+- Notification contacts for cluster alerts are configured in the **Support** tab
+- Machine pool editing allows changing node count per availability zone, node labels, and taints
+- The **Control plane type** field only appears for clusters using hosted control plane architecture
+- Availability zones can be **single** or **multizone**
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-understandin.md

@@ -0,0 +1,75 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/understanding-development
+source: sources/en-documentation-openshift_container_platform-417-html-architecture-understandin.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:23
+
+## Overview
+This page covers the fundamentals of developing containerized applications for OpenShift Container Platform, progressing from building simple containers through creating Kubernetes manifests to developing Operators. It explains the tools, base images, registries, workload types, and supporting components available in the OCP ecosystem.
+
+## Key Concepts
+- **Container development lifecycle**: Build image → push to registry → create K8s manifest → store in Git → optionally create an Operator
+- **Container build tools**: `buildah`, `podman`, and `skopeo` are daemonless, rootless tools preferred over Docker; they produce industry-standard OCI images
+- **CRI-O** is the container engine running on every worker and control plane node in OCP clusters (not supported standalone outside OCP)
+- **Red Hat Universal Base Images (UBI)**: Freely redistributable base images (standard, init, minimal variants) based on RHEL — no Red Hat subscription required to share
+- **Source-to-Image (S2I)**: Special runtime base images that let you insert code into a ready-to-run environment (Node.js, Perl, Python, etc.)
+- **Pods** are the basic deployable unit in Kubernetes (not containers); pods can contain multiple containers sharing network, storage, and IPC
+- **Services** group pods together, provide stable IP addresses, and enable load balancing; they persist until explicitly deleted
+- **Red Hat Registry**: `registry.redhat.io` (authenticated, current) and `registry.access.redhat.com` (unauthenticated, deprecated)
+- **Quay.io**: Red Hat-owned public registry; stores OCP components, container images, Helm charts, and Operators
+- **Red Hat Quay**: Private registry option with geo-replication, Git build triggers, and Clair image scanning
+- **OCP includes a built-in private container registry** installed with the cluster
+- **OperatorHub**: Marketplace for Operators from Red Hat, certified partners, and community — available in every OCP 4.x cluster
+- **Templates**: One-off application definitions with parameterized resource lists; shared templates often placed in the `openshift` namespace (accessible from all namespaces)
+
+## Commands and Syntax
+```bash
+# Build a container image using buildah
+buildah build-using-dockerfile .
+
+# Build using docker
+docker build .
+
+# Push image to registry
+podman push quay.io/myrepo/myapp:latest
+docker push quay.io/myrepo/myapp:latest
+
+# Pull and run
+podman run <image_name>
+docker run <image_name>
+
+# Apply a Kubernetes manifest
+oc apply -f <manifest.yaml>
+```
+
+## Relationships
+- **Workload types map to application needs**:
+  - Run-to-completion → `Job` / `CronJob`
+  - Long-running → `Deployment` / `DeploymentConfig`
+  - High availability → `Deployment` with `ReplicaSet`
+  - Every-node → `DaemonSet`
+  - Identity/numbering requirements → `StatefulSet`
+  - Lifecycle management → `Operator` (with OLM)
+- **Networking**: `NetworkPolicy` for fine-grained control; `Ingress` for external-to-internal routing
+- **Storage**: `Volumes` and `PersistentVolumes` for on-disk storage needs
+- **CI/CD and GitOps**: Manifests stored in Git; CI pipelines build images and push to registries
+- **Operator Lifecycle Manager (OLM)**: Manages Operator installation and updates; cluster admins expose Operators to selected namespaces
+
+## Exam-Relevant Points
+- **Docker as container runtime is deprecated** in Kubernetes 1.20 (but Docker-built images still work with all runtimes including CRI-O)
+- **CRI-O** runs on every node in OCP — it is the container runtime, not Docker
+- **UBI images are freely redistributable** without a Red Hat subscription
+- **S2I images** are accessible from the Developer perspective → +Add → Developer Catalog
+- **`registry.redhat.io`** requires authentication; `registry.access.redhat.com` is deprecated
+- **Pods** (not containers) are the basic unit of deployment, scaling, and management in Kubernetes
+- **Services** provide stable networking; resolved by name within the cluster
+- **StatefulSets** are for apps needing stable identity/numbering and independent storage (databases, zookeeper)
+- **DaemonSets** ensure a pod runs on every node (or a subset via node labels) — used for DNS, monitoring
+- **Templates** go in the `openshift` namespace for cluster-wide availability
+- **OperatorHub** is available in every OCP 4.x cluster
+- **`oc apply`** is the command to deploy Kubernetes manifests
+- Operators encode operational knowledge (backups, upgrades, scaling) and automate maintenance tasks
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture.md

@@ -0,0 +1,36 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture
+source: sources/en-documentation-openshift_container_platform-417-html-architecture.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:24
+
+## Overview
+This is the top-level landing page for the OpenShift Container Platform 4.17 Architecture documentation. It serves as an index page introducing the architecture section, which covers the platform and application architecture of OpenShift Container Platform. The page itself contains no substantive technical content — it links to sub-pages that contain the actual architectural details.
+
+## Key Concepts
+- OpenShift Container Platform 4.17 is the version documented
+- The architecture section covers both **platform architecture** (infrastructure, control plane, nodes) and **application architecture** (how workloads run on the platform)
+- Documentation is maintained by the Red Hat OpenShift Documentation Team
+- Available in multi-page, single-page, and PDF formats
+
+## Commands and Syntax
+None on this page (index/landing page only).
+
+## Relationships
+- This is the parent page for all architecture sub-topics, which typically include:
+  - **Installation and update architecture** — how the platform is deployed
+  - **Control plane architecture** — API server, etcd, controllers, scheduler
+  - **Node architecture** — kubelet, CRI-O, worker nodes
+  - **Networking architecture** — SDN/OVN-Kubernetes, Services, Routes
+  - **Storage architecture** — persistent volumes, CSI drivers
+  - **RHCOS (Red Hat Enterprise Linux CoreOS)** — the immutable OS layer
+- Foundational to understanding all other OCP documentation sections
+
+## Exam-Relevant Points
+- OpenShift Container Platform 4.17 is a current supported version
+- Understanding the distinction between **platform architecture** and **application architecture** is fundamental to the exam
+- The architecture section is the conceptual foundation — exam questions often test understanding of how components relate to each other at the architectural level
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authentication_and_author.md

@@ -0,0 +1,11 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authentication_and_authorization/legal-notice
+source: sources/en-documentation-openshift_container_platform-417-html-authentication_and_author.md
+---
+# En Documentation Openshift_Container_Platform 417 Html Authentication_And_Author
+
+**Date:** 2026-03-05
+**Time:** 13:24
+
+This is just a legal notice / copyright page — it contains no technical content relevant to OpenShift expertise or certification. No summary needed; skipping.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md

@@ -0,0 +1,58 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/authorization-apis
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:24
+
+## Overview
+This page catalogs the Authorization API resources available in OpenShift Container Platform 4.17. These APIs span two API groups — the OpenShift-native `authorization.openshift.io/v1` and the upstream Kubernetes `authorization.k8s.io/v1` and `authentication.k8s.io/v1` — and provide mechanisms for checking user/group permissions, requesting tokens, and reviewing authentication status.
+
+## Key Concepts
+- **Two parallel API groups** exist for authorization: OpenShift's `authorization.openshift.io/v1` (6 resources) and Kubernetes' `authorization.k8s.io/v1` (4 resources). Both provide similar access review capabilities.
+- **AccessReview resources** answer "can user X do action Y?" — they are the mechanism for programmatic authorization checks.
+- **Local vs. cluster-scoped**: Resources prefixed with "Local" (e.g., `LocalSubjectAccessReview`, `LocalResourceAccessReview`) are namespace-scoped; non-local variants operate cluster-wide.
+- **ResourceAccessReview** returns *which* users/groups can perform an action (OpenShift-only, no Kubernetes equivalent listed).
+- **SubjectAccessReview** checks whether a *specific* user/group can perform an action.
+- **SelfSubjectAccessReview / SelfSubjectRulesReview** let the *current* user check their own permissions.
+- **SelfSubjectRulesReview** (k8s) explicitly warns: should be used for UI show/hide only, **NOT** for driving external authorization decisions (confused deputy / cache concerns).
+- **SubjectRulesReview** (OpenShift) lets you check what *another* user can do in a namespace.
+- **TokenRequest** requests a token for a service account.
+- **TokenReview** authenticates a bearer token to a known user; results may be cached by the webhook token authenticator.
+- **SelfSubjectReview** (authentication) returns the user info the API server has about the requesting user; respects impersonation.
+- All OpenShift authorization resources are **Compatibility level 1** — stable within a major release for ≥12 months or 3 minor releases.
+
+## Commands and Syntax
+No specific CLI commands are shown on this reference page, but these APIs are typically consumed via:
+```bash
+# Check if you can perform an action
+oc auth can-i <verb> <resource> [-n <namespace>]
+
+# Check if another user can perform an action
+oc auth can-i <verb> <resource> --as=<user>
+
+# List your permissions in a namespace
+oc auth can-i --list [-n <namespace>]
+
+# Create a TokenRequest for a service account
+oc create token <service-account-name>
+```
+Programmatically, these are `POST`-based resources (you create a review object and the API server responds with the result).
+
+## Relationships
+- **RBAC**: These APIs *query* the RBAC system (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) — they don't define policy, they evaluate it.
+- **Authentication APIs**: `TokenRequest`, `TokenReview`, and `SelfSubjectReview` bridge authentication and authorization — establishing identity before checking permissions.
+- **Service Accounts**: `TokenRequest` ties directly to service account token management (bound tokens with audience/expiry).
+- **Impersonation**: `SelfSubjectReview` reflects impersonated identity, connecting to the `--as` / impersonation header mechanism.
+- **OAuth / Identity Providers**: These APIs operate downstream of authentication — once identity is established by OAuth or other providers, these APIs evaluate what that identity can do.
+
+## Exam-Relevant Points
+- Know the difference between **OpenShift** (`authorization.openshift.io`) and **Kubernetes** (`authorization.k8s.io`) authorization API groups — OpenShift has `ResourceAccessReview` and `SubjectRulesReview` which Kubernetes does not.
+- **`SelfSubjectRulesReview`** should NOT be used for external authorization decisions — only for UI hints. `SubjectAccessReview` is the correct API for authorization decisions.
+- **`LocalSubjectAccessReview`** is namespace-scoped, making it easier to grant namespace-scoped permissions that include the ability to check permissions.
+- **`TokenReview`** responses may be **cached** by the webhook authenticator — important for understanding token revocation behavior.
+- `oc auth can-i` is the CLI equivalent of creating SubjectAccessReview / SelfSubjectAccessReview resources.
+- All listed OpenShift authorization resources are type `object` with **Compatibility level 1** stability guarantees.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md

@@ -0,0 +1,38 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/index
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:24
+
+## Overview
+This is the reference landing page for OpenShift Container Platform 4.17 Authorization API objects. It serves as an index to the detailed specifications of all authorization-related API resources in OpenShift.
+
+## Key Concepts
+- **Authorization APIs** are a distinct category of API objects in OpenShift Container Platform, separate from other API groups (e.g., networking, storage, workloads)
+- These APIs govern **access control** — determining who can do what within a cluster
+- The authorization API group covers the Kubernetes and OpenShift-specific resources that enforce RBAC and permissions
+- Available across OCP versions from 3.x through 4.17+
+
+## Commands and Syntax
+No specific commands or syntax provided on this index page. Authorization API objects are typically interacted with via:
+```bash
+oc api-resources --api-group=authorization.openshift.io
+oc api-resources --api-group=rbac.authorization.k8s.io
+```
+
+## Relationships
+- **RBAC resources**: Roles, ClusterRoles, RoleBindings, ClusterRoleBindings are core authorization API objects
+- **OpenShift-specific authorization**: SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview, SelfSubjectRulesReview
+- Connects to **Authentication APIs** (authn establishes identity; authz determines permissions)
+- Relates to **Security Context Constraints (SCCs)** which control pod-level permissions
+- Ties into **OAuth and identity providers** for determining user/group membership used in bindings
+
+## Exam-Relevant Points
+- Authorization APIs are a **separate API group** from authentication — know the distinction
+- OpenShift extends Kubernetes RBAC with additional authorization API objects (e.g., `authorization.openshift.io` group)
+- Understanding which API objects fall under "authorization" vs other categories is testable
+- The authorization API reference covers OCP-specific objects beyond standard Kubernetes RBAC
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md

@@ -0,0 +1,11 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/legal-notice
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md
+---
+# En Documentation Openshift_Container_Platform 417 Html Authorization_Apis Legal 
+
+**Date:** 2026-03-05
+**Time:** 13:24
+
+This is just a legal notice/copyright page — it contains no technical content relevant to OpenShift expertise or certification. There's nothing meaningful to summarize here. Skip this page.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md

@@ -0,0 +1,65 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/localresourceaccessreview-authorization-openshift-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:25
+
+## Overview
+LocalResourceAccessReview is an OpenShift-specific authorization API resource (`authorization.openshift.io/v1`) that allows querying which users and groups are authorized to perform a specified action within a particular namespace. It is a Compatibility Level 1 resource, meaning it is stable within a major release for at least 12 months or 3 minor releases.
+
+## Key Concepts
+- **Purpose**: Determines *who* (users and groups) can perform a specific action on a specific resource in a given namespace
+- **Namespace-scoped**: Unlike `ResourceAccessReview` (cluster-wide), this is scoped to a particular namespace
+- **Request-only resource**: You POST a review request describing an action; the response lists authorized users/groups
+- **Required fields**: `namespace`, `verb`, `resourceAPIGroup`, `resourceAPIVersion`, `resource`, `resourceName`, `path`, `isNonResourceURL`
+- **Supported verbs**: `get`, `list`, `watch`, `create`, `update`, `delete`
+- **Non-resource URLs**: Can also check access to non-resource URL paths (outside the resource hierarchy) via `isNonResourceURL` and `path` fields
+- **API group**: `authorization.openshift.io/v1` — this is an OpenShift-specific API, not the upstream Kubernetes `authorization.k8s.io` API
+
+## Commands and Syntax
+
+**API Endpoint:**
+```
+POST /apis/authorization.openshift.io/v1/namespaces/{namespace}/localresourceaccessreviews
+```
+
+**Example request body structure:**
+```json
+{
+  "apiVersion": "authorization.openshift.io/v1",
+  "kind": "LocalResourceAccessReview",
+  "namespace": "my-project",
+  "verb": "create",
+  "resource": "pods",
+  "resourceAPIGroup": "",
+  "resourceAPIVersion": "v1",
+  "resourceName": "",
+  "path": "",
+  "isNonResourceURL": false
+}
+```
+
+**Query parameters:**
+- `dryRun` — set to `All` to validate without persisting
+- `fieldValidation` — `Ignore` (default pre-v1.23), `Warn` (default v1.23+), or `Strict`
+
+**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized
+
+## Relationships
+- **LocalResourceAccessReview vs ResourceAccessReview**: Local is namespace-scoped; `ResourceAccessReview` is cluster-scoped
+- **LocalResourceAccessReview vs LocalSubjectAccessReview**: LocalResourceAccessReview asks "who can do X?"; `LocalSubjectAccessReview` asks "can user Y do X?"
+- **RBAC connection**: Results reflect the effective RBAC policies (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings)
+- **OpenShift-specific**: Part of the `authorization.openshift.io` API group, complementing the upstream Kubernetes `SubjectAccessReview` in `authorization.k8s.io`
+- **CLI equivalent**: `oc adm policy who-can <verb> <resource> -n <namespace>` uses this API under the hood
+
+## Exam-Relevant Points
+- LocalResourceAccessReview answers **"who can do this?"** within a namespace — distinguish from SubjectAccessReview which answers **"can this user do this?"**
+- The API group is `authorization.openshift.io/v1` (OpenShift-specific, not upstream Kubernetes)
+- It is **namespace-scoped** — the namespace is part of the URL path
+- The only HTTP method supported is **POST** (it's a create-only subresource)
+- Know the distinction: `LocalResourceAccessReview` (namespace) vs `ResourceAccessReview` (cluster-wide)
+- Compatibility Level 1 = stable API guaranteed for 12 months or 3 minor releases
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md

@@ -0,0 +1,70 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/localsubjectaccessreview-authorization-k8s-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:25
+
+
+
+## Overview
+LocalSubjectAccessReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) that checks whether a user or group can perform a specific action within a given namespace. It is namespace-scoped, making it easier to grant namespace-level policies that include permissions checking.
+
+## Key Concepts
+- **Namespace-scoped authorization check**: Unlike `SubjectAccessReview` (cluster-scoped), `LocalSubjectAccessReview` operates within a specific namespace
+- **Spec is required**: The `spec` field is the only required field and describes the access request
+- **Two attribute types** (exactly one must be set):
+  - `resourceAttributes` — for resource requests (e.g., can user X get pods?)
+  - `nonResourceAttributes` — for non-resource requests (e.g., can user X access /healthz?)
+- **Status fields**:
+  - `allowed` (required boolean) — whether the action would be permitted
+  - `denied` (optional boolean) — explicit denial; if both `allowed` and `denied` are false, the authorizer has no opinion
+  - `evaluationError` — indicates an error during the check, but authorization may still proceed
+  - `reason` — explains why access was allowed or denied
+- The `user` field without `groups` is interpreted as "what if user were not a member of any groups"
+- Wildcard `"*"` can be used for group, resource, verb, and version fields to mean "all"
+
+## Commands and Syntax
+**API Endpoint:**
+```
+POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviews
+```
+
+**Query parameters:** `dryRun`, `fieldValidation` (Ignore/Warn/Strict)
+
+**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized
+
+**Example spec structure:**
+```yaml
+apiVersion: authorization.k8s.io/v1
+kind: LocalSubjectAccessReview
+metadata:
+  namespace: my-namespace
+spec:
+  user: "jane"
+  groups: ["developers"]
+  resourceAttributes:
+    namespace: "my-namespace"
+    verb: "get"
+    resource: "pods"
+    group: ""
+    version: "v1"
+```
+
+## Relationships
+- **SubjectAccessReview** — cluster-scoped equivalent for checking permissions across the entire cluster
+- **SelfSubjectAccessReview** — allows a user to check their own permissions
+- **RBAC (Roles/RoleBindings)** — the authorization backend that typically evaluates these reviews
+- **Namespace policies** — LocalSubjectAccessReview is the mechanism for programmatically verifying namespace-scoped RBAC grants
+
+## Exam-Relevant Points
+- LocalSubjectAccessReview is **namespace-scoped**; SubjectAccessReview is **cluster-scoped**
+- Exactly **one of** `resourceAttributes` or `nonResourceAttributes` must be set in the spec
+- The `allowed` field in `.status` is **required**; `denied` is optional
+- When `allowed=false` and `denied=false`, the authorizer has **no opinion** (not the same as denied)
+- The `verb` field in `resourceAttributes` uses Kubernetes API verbs (`get`, `list`, `watch`, `create`, `update`, `delete`, `proxy`), not HTTP verbs
+- The `verb` field in `nonResourceAttributes` uses standard **HTTP verbs**
+- Empty string `""` for namespace in LocalSubjectAccessReview defaults to the review's own namespace
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md

@@ -0,0 +1,63 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/resourceaccessreview-authorization-openshift-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:25
+
+## Overview
+ResourceAccessReview is an OpenShift-specific authorization API resource (`authorization.openshift.io/v1`) that allows requesting a list of which users and groups are authorized to perform a specified action. It is a cluster-scoped review (not namespace-scoped) and is classified as Compatibility Level 1, meaning it is stable within a major release for at least 12 months or 3 minor releases.
+
+## Key Concepts
+- **Purpose**: Determines *who* (users and groups) can perform a given action, as opposed to determining *whether* a specific user can perform an action (which is what SubjectAccessReview does).
+- **Cluster-scoped**: The endpoint has no namespace prefix — it operates at the cluster level.
+- **Required fields**: `namespace`, `verb`, `resourceAPIGroup`, `resourceAPIVersion`, `resource`, `resourceName`, `path`, `isNonResourceURL`.
+- **Verb values**: One of `get`, `list`, `watch`, `create`, `update`, `delete`.
+- **Non-resource URLs**: Supports checking access to non-resource URL paths (outside the resource hierarchy) via `isNonResourceURL` and `path`.
+- **OpenShift-specific**: This is an OpenShift extension (`authorization.openshift.io/v1`), not a upstream Kubernetes API.
+
+## Commands and Syntax
+
+**API Endpoint:**
+```
+POST /apis/authorization.openshift.io/v1/resourceaccessreviews
+```
+
+**Example body structure:**
+```json
+{
+  "apiVersion": "authorization.openshift.io/v1",
+  "kind": "ResourceAccessReview",
+  "namespace": "my-namespace",
+  "verb": "get",
+  "resource": "pods",
+  "resourceAPIGroup": "",
+  "resourceAPIVersion": "v1",
+  "resourceName": "",
+  "path": "",
+  "isNonResourceURL": false
+}
+```
+
+**Query parameters:**
+- `dryRun` — simulate without persisting (valid value: `All`)
+- `fieldValidation` — controls handling of unknown/duplicate fields (`Ignore`, `Warn`, `Strict`)
+
+**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized.
+
+## Relationships
+- **LocalResourceAccessReview**: The namespace-scoped counterpart — checks who can perform an action within a specific namespace.
+- **SubjectAccessReview / SelfSubjectAccessReview**: The inverse question — checks whether a *specific* user/subject can perform an action, rather than listing *all* authorized users.
+- **RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings)**: ResourceAccessReview evaluates the results of RBAC policies to produce its answer.
+- **`oc adm policy who-can`**: The CLI command that likely uses this API under the hood to answer "who can perform action X on resource Y."
+
+## Exam-Relevant Points
+- ResourceAccessReview answers "who can do X?" — it returns users and groups authorized for a specific action.
+- It is an OpenShift-specific API under `authorization.openshift.io/v1`, not a standard Kubernetes API.
+- The API is cluster-scoped (no namespace in the URL path).
+- Required fields include `verb`, `resource`, `namespace`, `resourceAPIGroup`, and `resourceAPIVersion`.
+- Valid verbs are: `get`, `list`, `watch`, `create`, `update`, `delete`.
+- Compatibility Level 1 means stable for 12 months or 3 minor releases minimum.
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md

@@ -0,0 +1,75 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/selfsubjectrulesreview-authorization-k8s-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:26
+
+## Overview
+
+SelfSubjectRulesReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) that enumerates the set of actions the current user can perform within a specific namespace. It is designed for UI purposes (show/hide actions) and quick permission reasoning, but explicitly should **not** be used by external systems for authorization decisions.
+
+## Key Concepts
+
+- **Purpose**: Lets the current user discover what actions they are allowed to perform in a given namespace
+- **Results may be incomplete**: The returned list depends on the server's authorization mode and any errors during evaluation
+- **Additive rules model**: If a rule appears in the results, the subject definitely has that permission, even if the list is incomplete
+- **Not for authorization decisions**: External systems should use `SubjectAccessReview` or `LocalAccessReview` instead — using SelfSubjectRulesReview raises confused deputy, caching, and correctness concerns
+- **Two rule categories in status**:
+  - `resourceRules` — actions allowed on Kubernetes resources (verbs: get, list, watch, create, update, delete, proxy)
+  - `nonResourceRules` — actions allowed on non-resource URLs (verbs: get, post, put, delete, patch, head, options)
+- **`incomplete` flag**: Boolean in status indicating whether the results are partial (e.g., when an external authorizer doesn't support rules evaluation)
+- **`evaluationError`**: String field reporting errors during rule evaluation
+
+## Commands and Syntax
+
+**API Endpoint:**
+```
+POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews
+```
+
+**Spec** (required field):
+```yaml
+spec:
+  namespace: "my-namespace"   # Required — namespace to evaluate rules for
+```
+
+**Status response structure:**
+```yaml
+status:
+  incomplete: false
+  evaluationError: ""
+  resourceRules:
+    - apiGroups: [""]
+      resources: ["pods"]
+      resourceNames: []
+      verbs: ["get", "list", "watch"]
+  nonResourceRules:
+    - nonResourceURLs: ["/healthz"]
+      verbs: ["get"]
+```
+
+**Query parameters:** `dryRun`, `fieldValidation` (Ignore/Warn/Strict)
+
+**HTTP responses:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized
+
+## Relationships
+
+- **SubjectAccessReview / LocalSubjectAccessReview**: The correct alternatives for programmatic authorization decisions (SelfSubjectRulesReview is only for UI/informational use)
+- **RBAC**: The rules returned reflect the cumulative effect of Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings
+- **Namespace-scoped**: Requires a namespace in the spec; evaluates permissions within that namespace context
+- **Wildcard `*`**: Used across apiGroups, resources, resourceNames, verbs, and nonResourceURLs to mean "all"
+
+## Exam-Relevant Points
+
+- SelfSubjectRulesReview is for **UI display purposes only**, not for driving authorization decisions
+- The correct APIs for authorization decisions are **SubjectAccessReview** and **LocalSubjectAccessReview**
+- Results can be **incomplete** — the `incomplete` boolean and `evaluationError` string indicate this
+- Authorization rules are **additive** — presence in the list confirms permission even if the list is incomplete
+- The spec requires a **namespace** field
+- The API group is `authorization.k8s.io/v1`
+- Only supports **POST** (create) — no GET/LIST/DELETE operations
+- `resourceRules` cover API resources; `nonResourceRules` cover URL paths like `/healthz`
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md

@@ -0,0 +1,66 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/subjectaccessreview-authorization-k8s-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:26
+
+## Overview
+SubjectAccessReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) used in OpenShift to programmatically check whether a specific user or group can perform a given action. It enables imperative authorization queries against the cluster's authorization layer (typically RBAC).
+
+## Key Concepts
+- **SubjectAccessReview** checks if a user/group is authorized to perform an action — returns allowed/denied status
+- The `spec` field is required and must contain exactly one of `resourceAttributes` or `nonResourceAttributes`
+- **ResourceAttributes**: checks access to Kubernetes resources (pods, services, etc.) with fields for group, name, namespace, resource, subresource, verb, and version
+- **NonResourceAttributes**: checks access to non-resource URL paths (e.g., `/healthz`) using HTTP verbs
+- The `user` field specifies the subject to test; if `groups` is omitted, the check treats the user as having no group memberships
+- `extra` maps to authenticator-provided extra info (passed through to the authorizer)
+- **Status fields**: `allowed` (required boolean), `denied` (optional boolean), `reason` (human-readable explanation), `evaluationError` (error during check that may not be fatal)
+- If both `allowed` and `denied` are false, the authorizer has no opinion (neither permits nor denies)
+- Wildcard `"*"` can be used for group, resource, verb, and version to mean "all"
+
+## Commands and Syntax
+
+**API Endpoint:**
+```
+POST /apis/authorization.k8s.io/v1/subjectaccessreviews
+```
+
+**Example: Check if user "jane" can get pods in namespace "dev":**
+```yaml
+apiVersion: authorization.k8s.io/v1
+kind: SubjectAccessReview
+spec:
+  user: "jane"
+  resourceAttributes:
+    namespace: "dev"
+    verb: "get"
+    resource: "pods"
+```
+
+**Using `oc` CLI:**
+```bash
+oc auth can-i get pods --as=jane -n dev
+```
+
+**Query parameters:** `dryRun` (skip persistence), `fieldValidation` (Ignore/Warn/Strict for unknown fields)
+
+**HTTP responses:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized
+
+## Relationships
+- **SelfSubjectAccessReview**: similar but checks the calling user's own permissions (no `user`/`groups` fields)
+- **LocalSubjectAccessReview**: namespace-scoped variant (defaults empty namespace to the target namespace)
+- **RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings)**: the authorization backend that SubjectAccessReview queries against
+- **Authentication/User Info**: the `user`, `groups`, `uid`, and `extra` fields mirror what the authenticator provides
+- **`oc auth can-i`**: CLI wrapper around SubjectAccessReview and SelfSubjectAccessReview
+
+## Exam-Relevant Points
+- SubjectAccessReview is **cluster-scoped** (not namespaced) — there is a single endpoint, not per-namespace
+- Exactly **one of** `resourceAttributes` or `nonResourceAttributes` must be set in the spec
+- The `allowed` field in `.status` is **required**; `denied`, `reason`, and `evaluationError` are optional
+- Empty string for `namespace` in resourceAttributes means **"all namespaces"** for namespace-scoped resources in SubjectAccessReview
+- Resource verbs are Kubernetes verbs (`get`, `list`, `watch`, `create`, `update`, `delete`, `proxy`), not HTTP verbs — HTTP verbs are used only for nonResourceAttributes
+- The `oc auth can-i --as=<user>` command is the practical CLI equivalent of creating a SubjectAccessReview
+

entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md

@@ -0,0 +1,59 @@
+---
+source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/tokenreview-authentication-k8s-io-v1
+source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md
+---
+# Overview
+
+**Date:** 2026-03-05
+**Time:** 13:26
+
+
+
+## Overview
+The TokenReview resource (`authentication.k8s.io/v1`) is a Kubernetes API object used to authenticate a bearer token and resolve it to a known user. OpenShift exposes TokenReview through both the standard Kubernetes endpoint and an OpenShift-specific OAuth endpoint. TokenReview requests may be cached by the webhook token authenticator plugin in the kube-apiserver.
+
+## Key Concepts
+- **TokenReview** is a `POST`-only API — it validates a token and returns user identity information; it does not create persistent resources.
+- The `spec` field is **required** and contains the opaque bearer token to validate.
+- **Audiences**: Both `spec` and `status` carry an `audiences` field. The spec declares which audiences the token should be valid for; the status returns the intersection of requested and actual audiences.
+- If no audiences are specified in the spec, the default audience is the Kubernetes API server itself.
+- The `status.authenticated` boolean indicates whether the token mapped to a known user.
+- `status.user` returns resolved identity: `username`, `uid`, `groups`, and optional `extra` key-value pairs.
+- A `uid` uniquely identifies a user across time — if a user is deleted and recreated with the same name, the UID will differ.
+
+## Commands and Syntax
+**API Endpoints (POST only):**
+- `/apis/authentication.k8s.io/v1/tokenreviews` — standard Kubernetes endpoint
+- `/apis/oauth.openshift.io/v1/tokenreviews` — OpenShift OAuth endpoint
+
+**Query Parameters:**
+- `dryRun=All` — process all stages without persisting (though TokenReview is non-mutating anyway)
+- `fieldValidation` — `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), or `Strict`
+
+**Response Codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized
+
+**Example spec structure:**
+```yaml
+apiVersion: authentication.k8s.io/v1
+kind: TokenReview
+spec:
+  token: "<bearer-token>"
+  audiences:
+    - "https://kubernetes.default.svc"
+```
+
+## Relationships
+- **Authentication & Authorization chain**: TokenReview is the programmatic way to verify tokens, used by webhook token authenticators and API server authentication plugins.
+- **OAuth tokens**: The OpenShift-specific endpoint (`oauth.openshift.io/v1`) ties into OpenShift's OAuth server and OAuth access tokens.
+- **ServiceAccount tokens**: Projected service account tokens can be validated via TokenReview with audience restrictions.
+- **RBAC**: After TokenReview resolves identity, authorization decisions (via SubjectAccessReview, Roles, ClusterRoles) use the returned user/group info.
+- Related APIs: **SubjectAccessReview** (authorization check), **SelfSubjectAccessReview**, **OAuthAccessToken**.
+
+## Exam-Relevant Points
+- TokenReview has **two endpoints** in OpenShift: the Kubernetes-native one and the OpenShift OAuth one.
+- The `spec` field is the only **required** field on the TokenReview object.
+- `status.authenticated = true` with an empty `status.audiences` means the token is valid for the Kubernetes API server audience specifically.
+- Audience-aware clients **must** validate that a compatible audience is returned in `status.audiences`.
+- TokenReview results **may be cached** by the webhook token authenticator — this is a performance and security consideration.
+- The API group is `authentication.k8s.io/v1` (Kubernetes-native) or `oauth.openshift.io/v1` (OpenShift).
+