> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo A Quick Relook Into tagging rulesyaml

> Overview of Kubernetes tagging rules YAML for an airline booking context covering required tags, label mappings, allowed values, resource types, and namespace exclusions for governance and automation.

Hello and welcome back.

Before we change the prompt, let's quickly re-examine our `tagging-rules.yaml`. Below I’ll walk through the file structure, why each section matters for Kubernetes tagging and governance, and how to keep the configuration maintainable and agent-friendly.

Open `config/tagging-rules.yaml` and you'll see several logical sections: required tags, label mappings, allowed values (cost centers, environments, tiers, compliance levels), resource types, and excluded namespaces. Here is a consolidated, production-ready example of the YAML configuration used in an airline booking context:

```yaml theme={null}
# Tagging Rules Configuration
required_tags:
  - owner
  - environment
  - cost-center
  - application
  - tier
  - slack-channel

label_mappings:
  owner:
    - app.kubernetes.io/owner
    - owner
  environment:
    - app.kubernetes.io/env
    - environment
    - env
  cost-center:
    - app.kubernetes.io/cost-center
    - cost-center
    - costcenter
  application:
    - app.kubernetes.io/name
    - app
    - application
  tier:
    - app.kubernetes.io/tier
    - tier
  compliance:
    - compliance-level
    - compliance
  slack-channel:
    - app.kubernetes.io/slack-channel
    - slack-channel
    - slack_channel

cost_centers:
  - booking-engine
  - payment
  - inventory
  - customer-service
  - analytics
  - platform

environments:
  - dev
  - staging
  - prod

tiers:
  - frontend
  - backend
  - database
  - cache
  - messaging

compliance_levels:
  - pci-dss
  - sox
  - standard

resource_types:
  - Deployment
  - Service
  - ConfigMap
  - PersistentVolumeClaim
  - Ingress
  - Pod

excluded_namespaces:
  - kube-system
  - kube-public
  - kube-node-lease
  - local-path-storage
```

Quick reference: file sections and purpose

| Section | Purpose | Example / Notes |
| - | - | - |
| `required_tags` | Tags every resource must have | `owner`, `environment`, `cost-center` |
| `label_mappings` | Normalize different label keys to canonical tags | Maps `env`, `environment`, `app.kubernetes.io/env` → `environment` |
| `cost_centers`, `environments`, `tiers`, `compliance_levels` | Lists of allowed values to enforce consistency | Use enumerated values to validate incoming resources |
| `resource_types` | Which Kubernetes resources the agent should process | e.g., `Deployment`, `Service`, `Pod` |
| `excluded_namespaces` | Namespaces the agent must ignore | `kube-system`, `kube-public`, etc. |

Required tags

* The `required_tags` list defines canonical metadata every application resource should include. Your agent/tooling should validate these and flag or remediate resources missing any required tag. This drives consistent ownership, cost allocation, and environment separation across clusters.

Label mappings

* `label_mappings` lets multiple teams keep their existing labels while your agent normalizes them to canonical tags. This reduces churn and redeploy work by interpreting `app.kubernetes.io/name`, `app`, and `application` as the same canonical `application` tag.

Label mappings reduce operational friction: allow teams to use commonly adopted label keys while your tooling maps them to a single canonical tag for policy checks, billing, and search.

Slack channel nuance

* We added `slack-channel` as a required tag. Many teams use either `slack-channel` or `slack_channel`; the difference between a dash (`-`) and an underscore (`_`) matters in Kubernetes label keys. Include both variants in `label_mappings` to avoid forcing label changes across existing resources.

Kubernetes label keys are exact strings. If you expect multiple naming conventions (dash vs underscore), explicitly map each variant in `label_mappings` to prevent false negatives during validation.

Allowed values and resource control

* Use lists such as `cost_centers`, `environments`, `tiers`, and `compliance_levels` to constrain allowed values. This makes automated checks and reporting deterministic (e.g., cost allocation by `cost-center` or environment-based promotion pipelines).
* `resource_types` defines which Kubernetes kinds the agent should inspect or enforce tags for. Narrow this list to reduce noise and resource usage.
* `excluded_namespaces` prevents the agent from touching system or irrelevant namespaces (for example, `kube-system`), improving performance and avoiding unintended modifications.

Why YAML (not JSON)

* YAML is more human-friendly for configuration: it handles comments, is easier to read, and is forgiving for adding/removing lists—helpful for operational configs like tagging rules.
* JSON is stricter and can be used where required, but for day-to-day governance config files, YAML improves maintainability and reduces accidental schema breakage.

Helpful links and references

* Kubernetes labels & annotations: [https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
* YAML specification and best practices: [https://yaml.org/](https://yaml.org/)
* Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/)

That is a quick relook into what `tagging-rules.yaml` should contain and why. Next, we'll go into the prompting section.

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/5045eac8-8b03-4ecd-9213-d50eda3353c5/lesson/f201d0c7-d0b9-4c6e-8947-421252f0c665)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.