Skip to main content
Your progress
0 of 5 lessons complete0%
T1 / M1.2 / L2 OF 5 / Operator TIER / 10 min

Parent-child hierarchies

Outcome

By the end of this lesson, you will be able to navigate the parent-child hierarchy in the resource list and drill from a cluster to its individual child workloads in three or fewer clicks.


TierOperator
JTBD”Find a specific K8s CronJob nested under a cluster’s nodegroup.”
PersonasPlatform Engineer
PrerequisitesL1
Time10 minutes
Bloom verbNavigate (Apply)

1. Concept

Cloud resources come in nests, not in a flat list.

A Kubernetes cluster holds groups of machines, and those groups hold the machines themselves. The same cluster separately holds the applications running on it. An Azure Databricks workspace holds clusters, instance pools and SQL warehouses. An ECS cluster holds services, and each service holds the tasks doing the work.

ZopNight works out which things belong to which, and lets you navigate down through them. Throughout this lesson, a parent is the thing that contains, and a child is what it contains.

The hierarchy model

Terminal window
TOP-LEVEL PARENT CHILDREN (one level down)
─────────────────────────────────────────────────────────────
EKS / GKE / AKS cluster → Nodegroup, Deployment, STS, CronJob
ECS cluster → Service, Task definition, Container instance
Databricks Workspace → Cluster, Instance Pool, SQL Warehouse
ECR repository → Image
Artifact Registry repository → Image
CloudWatch → Log Group
RDS instance → Read replica (if any)
ASG → Instance, Scheduled action

Some hierarchies go three levels deep:

Terminal window
LEVEL 1 LEVEL 2 LEVEL 3
─────────────────────────────────────────────────────────
EKS cluster → Nodegroup → EC2 instance
GKE cluster → Node pool → GCE instance
AKS cluster → Node pool → Azure VM

The default Resources view shows parents only. Each parent carries a child count badge. Clicking the badge or the parent itself drills into the children.

The default view

Terminal window
RESOURCES → Parents view (default)
NAME TYPE CHILDREN STATUS
─────────────────────────────────────────────────────────────────
prod-eks-cluster eks 3 child → Running
staging-databricks-ws databricks 12 child → Running
prod-ecr-payments ecr 847 child → -
prod-rds-payments rds 1 read replica → Available
build-asg-x86 asg 8 instances → Running

That count is a link. Click “3 child” on prod-eks-cluster and the page becomes that cluster’s contents: its machine groups and its workloads, and nothing from anywhere else.

When viewing children, a breadcrumb shows the path:

Terminal window
Resources > prod-eks-cluster > Nodegroup: gp-nodes-1 > Instances
Each segment is clickable. Click "prod-eks-cluster" to return to its children.
Click "Resources" to return to the all-parents view.

Nothing is a dead end. Three levels down, you can step back one at a time or jump straight to the top.

Filters narrow per scope

Filters describe where you are, not the whole estate. Inside prod-eks-cluster, the Type filter offers only the four kinds of thing that cluster actually contains, rather than all 380. You are never scrolling past types that cannot appear here.

Search overrides scope

Search is the exception. It looks across the whole estate and returns matches whatever they belong to, which is what you want when you know the name and have forgotten where it lives.

Why parent-child matters for scheduling

Kubernetes workloads are scheduled one child at a time, never a whole cluster at once. To stop one scheduled job outside working hours, you go:

Terminal window
Resources → prod-eks-cluster → cronjob-daily-report → Attach Schedule

Stopping the whole cluster would take the production applications down with it, which is almost never what anybody meant. Navigating into the child first makes the smaller, correct action the obvious one.

The same applies to Databricks. A team can schedule individual Databricks clusters or SQL warehouses off-hours without affecting other workspace components.

Why parent-child matters for cost

Cost attribution rolls up the hierarchy. A nodegroup’s cost is the sum of its instances. A cluster’s cost is the sum of its nodegroups. The Resources page shows the rolled-up monthly cost on the parent row and the per-child cost when drilled into the children.

Terminal window
prod-eks-cluster Monthly: $14,300
└── gp-nodes-1 (nodegroup) Monthly: $11,400
└── i-0abc1 (instance) Monthly: $722
└── i-0abc2 (instance) Monthly: $722
└──...
└── memory-nodes (nodegroup) Monthly: $2,900
└── i-0xyz1 (instance) Monthly: $972
└──...
└── cronjob-daily-report Monthly: included in nodegroup

The scheduled job has no compute cost of its own, because it runs on machines the group is already paying for. It still appears here, because you need somewhere to schedule it and something to point at when you talk about it.


2. Demo

A typical navigation path:

Terminal window
SCENARIO: Find and schedule a specific CronJob to zero off-hours
T+0 Open Resources page (Parents view)
T+5 s Find "prod-eks-cluster" with "12 child →" badge
T+8 s Click "12 child →"
Breadcrumb: Resources > prod-eks-cluster
View: 12 children (4 nodegroups, 6 Deployments, 1 STS, 1 CronJob)
T+12 s Filter Type=CronJob, search "report"
View narrowed to 1 CronJob: cronjob-daily-report
T+15 s Click the CronJob row
Detail page opens: shows resource UID, parent cluster, current schedule, cost
T+18 s Click "Attach Schedule" → schedule selector → pick "Weekend Off"
T+22 s Confirm
Schedule attached. The CronJob will be suspended on weekends.

22 seconds from estate view to scheduled. The hierarchy makes this fast.


3. Hands-on (7 min)

For your own estate:

Terminal window
1. Open Resources. Identify any parent with children (cluster, ECS service,
Databricks workspace, ASG, ECR repo).
2. Click the child count badge to drill in.
3. Note the breadcrumb at the top of the page.
4. Apply a filter (e.g., Type=Deployment).
5. Confirm the filter scope is local to this parent: toggle back to the
parent view and observe how the filter availability changes.
6. Use the search bar to find a specific resource by name.
7. Confirm search overrides scope: even if you're inside one cluster,
search returns matches from across the estate.

The exercise builds muscle memory for the navigation. Drill and back out multiple times.


4. Knowledge check

Q1

A team wants to suspend one specific Kubernetes CronJob outside business hours. The right navigation path is:

A. Schedule the entire EKS cluster off, which will take every other workload down with it as well
B. Use the AWS console
C. Delete the CronJob
D. Drill into the cluster’s children, find the specific CronJob, attach a schedule to that CronJob individually

Show answer

Correct: D. The parent-child model makes this child-level scheduling natural. Child-level scheduling is exactly what the hierarchy enables. Scheduling the entire cluster would stop production workloads too.

Q2

A user is three levels deep (Resources > Cluster > Nodegroup > Instances) and wants to return to the cluster level. The most efficient way is:

A. Click the “Cluster” segment in the breadcrumb
B. Use the browser back button twice
C. Navigate back from the Resources homepage
D. Refresh the page

Show answer

Correct: A. The breadcrumb is how you move around parent-child hierarchies. Breadcrumb segments are clickable navigation. This is the designed navigation pattern.

Q3

Inside a children view (one specific cluster’s children), the Type filter shows only types present in this cluster (not the full 380+ list). This is:

A. A bug
B. Intentional: filters are scoped to the current view to keep the UI relevant
C. Inconsistent with the rest of the product experience overall in the UI
D. A limitation

Show answer

Correct: B. Search, by contrast, overrides scope and operates across the entire estate. Filters narrow per scope; search overrides scope. This is the designed behavior because each one serves a different intent.


5. Apply

The Resources page implements the hierarchy as:

  • Default Parents view with child-count badges per parent
  • Click child badge → Children view with breadcrumb navigation
  • Per-scope filters that adapt to the current view
  • Global search that overrides scope

For specific workload patterns:

  • K8s workloads (Deployments, StatefulSets, CronJobs) are children of their cluster
  • Databricks (Clusters, Pools, SQL Warehouses) are children of their workspace

Glossary terms touched

Parent-child hierarchy · Breadcrumb · Scoped filter · Global search


Start with the bill.

Foundations takes about five hours. The first lesson is nine minutes.

Open curriculum. No login. No paywall. 290 lessons across 7 courses, three publicly verifiable credentials. Read it on the train, take the exam on a Saturday, list the credential on your résumé Monday.

5h median time to finish Foundations
0 logins, paywalls, or marketing forms
open curriculum, public credential verifier
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·