Grafana Admin common mistakes
Grafana Admin · Understand the traps and how to avoid them.
Treating Grafana's authentication and authorization layers as one setting, so a candidate enables OAuth login and then assumes group membership automatically maps to the right folder permissions.
It is easy to conflate authentication (who you are: OAuth, SAML, LDAP, basic auth) with authorization (what you can do: Org roles, teams, folder and dashboard permissions, RBAC). Candidates often study login configuration in isolation and never trace the second hop from identity provider groups to Grafana teams and roles.
What to do instead
For each auth provider, be able to state both halves: how the user is authenticated and how role/team mapping is configured (for example role_attribute_path or group-to-team sync). Practise writing the mapping expression and predicting the resulting Org role and team membership for a sample user.
Assuming a dashboard's folder permissions and its dashboard-level permissions combine by taking the most permissive of the two, rather than understanding inheritance and explicit overrides.
The permission model is hierarchical: folder permissions are inherited by dashboards, and dashboard-level permissions can grant or restrict further. Candidates who memorise 'Viewer, Editor, Admin' without the inheritance rules mispredict access for nested cases.
What to do instead
Work through concrete scenarios on a test instance: a user with Viewer on a folder but Editor on one dashboard, a team granted Edit on a folder, and an anonymous viewer. Record the effective permission for each and verify it in the UI before the exam.
Editing the Grafana configuration file directly on a running instance and expecting changes to take effect without a restart, or forgetting that environment variables override file settings.
Grafana reads its configuration at startup, and the precedence order (defaults, then the config file, then environment variables, then command-line flags) is a frequent blind spot. Candidates change grafana.ini, see no effect, and conclude the setting is wrong rather than unreloaded.
What to do instead
Memorise the precedence order and which settings require a restart versus which can be changed at runtime. When practising, change a setting via environment variable and via the file and confirm which wins, then restart and confirm the new value in the admin settings view.
Configuring a data source with a service account or API key that lacks the required scopes, then blaming Grafana when queries or provisioning fail.
Data source plugins authenticate to external systems (Prometheus, Loki, cloud APIs) with their own credentials, and the permissions needed are defined by the external system, not Grafana. Candidates focus on Grafana-side configuration and under-test the outbound credential.
What to do instead
For each data source type you expect, list the exact credential type and minimum permissions required, then test with the 'Save and test' button and a real query. Include a deliberate failure case (revoked token) so you recognise the error signature.
Writing provisioning YAML that works on first boot but silently overwrites or deletes manual changes, or fails to update existing resources because the unique identifier is wrong.
Provisioned dashboards and data sources are managed declaratively; the provider reconciles by UID or name and can delete resources removed from the files. Candidates test only the create path and are surprised by the update and delete behaviour.
What to do instead
Practise the full lifecycle: create via file, edit the file to change a panel, restart and observe the update, then remove the resource from the file and observe the deletion (and how allowUiUpdates or deleteDatasources change it). Know which fields form the identity.
Backing up only the Grafana SQLite database and assuming a restore will work, without accounting for the encryption key used for secrets such as data source passwords.
Stored secrets are encrypted with the secret key from the configuration. A database restored into an instance with a different or missing secret key leaves data sources unusable, and candidates rarely test a restore end to end.
What to do instead
Include the secret key (or its environment variable) in the backup plan alongside the database, provisioning files, and plugins list. Perform a restore into a fresh instance and verify a data source query succeeds, not just that Grafana starts.
Misreading how alert rules are evaluated and where notifications are routed, for example expecting a contact point to receive an alert that never entered the firing state or was silenced by a mute timing.
Alerting spans rule evaluation, alert state, notification policies with matchers and grouping, contact points, and silences. Candidates learn the UI screens separately and cannot trace why a specific alert produced no notification.
What to do instead
Build a small alerting tree on a practice instance: one rule, a notification policy with a matcher, a contact point, and a silence. Trigger the alert, confirm the notification, then add a silence and confirm suppression. Be able to explain each step in the pipeline.
Confusing organisation-level isolation with instance-level administration, such as expecting an Org Admin to manage users or settings outside their organisation.
Grafana has server admins and organisation admins with different scopes, and users can belong to multiple organisations with different roles in each. Candidates who only ever used a single default organisation miss the boundary.
What to do instead
Create a second organisation on a test instance and map out what a Server Admin, Org Admin, Editor, and Viewer can each see and change across organisations. Note which admin endpoints and settings are server-wide only.
Ignoring plugin management details, such as whether a plugin is signed, installed in the correct directory, or compatible with the Grafana version, and then diagnosing a load failure as a configuration error.
Plugins have signature verification, installation paths, and version constraints, and a failed plugin load surfaces as a missing data source or panel rather than an obvious error. Candidates skip the plugin lifecycle because it is not part of daily dashboard work.
What to do instead
Practise installing a plugin from the catalog and from a local file, checking the plugin signature state, and reading the server log for load errors. Know the setting that controls whether unsigned plugins are allowed and the risks of enabling it.
Sizing and tuning the instance by guesswork, for example leaving the default database and caching settings in place under load and then failing questions about scaling or performance troubleshooting.
Performance topics require knowing which components are stateful (database, session storage, image rendering) and how caching and rendering affect load. Candidates memorise feature names without understanding the operational trade-offs.
What to do instead
Study the deployment options (SQLite versus external database, session storage backends, the image renderer service) and the settings that govern them. For each, be able to say what breaks at scale and what you would change first, and verify by reading the metrics Grafana exposes.