If you work in IT, you probably learn something new almost every day.
One day, you’re debugging a Docker container. The next day, you’re fixing a Kubernetes deployment, writing a Terraform module, troubleshooting a CI/CD pipeline or figuring out why an application cannot connect to a database.
You spend hours understanding the problem. You search documentation, read blogs, try different solutions, and finally get things working.
Problem solved. You move on to the next task.
But a few months later, you face a similar problem. You remember solving it before, but you don’t remember exactly how. You start searching Google again, ask AI again, but feel AI options will not work for some reasons then, open multiple browser tabs, and spend time learning something you have already learned once.
Sound familiar?
This is one of the biggest problems with learning while working in IT. We learn a lot, but we don’t always retain what we learn.
This is where NoteTaking tool can help. After trying out different tools in the market I settled with Obsidian.
Disclaimer: This post is not sponsored by Obsidian or any other brand. These are purely my personal experiences and opinions. But hey, that doesn’t mean Obsidian can’t pay me someday! 😛
Instead of keeping your technical knowledge scattered across browser bookmarks, text files, screenshots, and random documents, you can build your own technical knowledge base.
Not a company document repository. Not a place to copy project information. Just your personal collection of technical concepts, reusable examples, troubleshooting methods, commands, and lessons learned.
Let’s see how to build one.
Obsidian is a note-taking application that stores notes as Markdown files.
Think of it as your own technical notebook, but with a useful feature: you can link related notes together.
For example, imagine you work with AWS, Terraform, Docker, Kubernetes, and GitHub Actions.
You might create notes such as:
Initially, these are just individual notes.
Later, you can connect Terraform notes to AWS infrastructure, Kubernetes notes to container networking, and deployment troubleshooting notes to CI/CD pipelines.
Over time, you build a technical reference library based on your own learning.
The advantage is simple: when you encounter a similar problem in the future, you can refer to your own notes instead of starting from scratch.
This is especially important if you work in consulting, IT services, cloud engineering, DevOps, cybersecurity, or enterprise application development.
Your goal is to retain technical knowledge, not client information.
You should never copy confidential client data, proprietary configurations, credentials, internal URLs, customer information, or restricted project documentation into your personal vault.
Follow your employer’s information security policies and any applicable client agreements. Even seemingly harmless details can be sensitive when combined.
So, what can you document?
| Avoid storing | Safe, reusable alternative |
|---|---|
| Actual client infrastructure configuration | A generic Terraform example |
| Client-specific pipeline YAML | A sample CI/CD pipeline using fictional values |
| Production logs containing internal details | A synthetic log showing the same error pattern |
| Real account IDs, hostnames, or internal URLs | Clearly fictional placeholders |
| Client architecture diagrams | A generic architecture diagram based on public concepts |
| Proprietary troubleshooting documents | Your own explanation of the underlying technical concept |
| Credentials, tokens, secrets, or certificates | A note explaining secret-management best practices |
For example, suppose you troubleshoot an authentication failure in a Kubernetes workload.
You don’t need to document which client experienced the issue, which cluster was involved, or what the actual service account was called.
Instead, document the technical lesson:
Topic: Kubernetes workload authentication failures
What I learned: A workload may fail to access a cloud resource because of an incorrect identity binding, missing permissions, or an improperly configured workload identity mechanism.
How to troubleshoot: Verify the workload identity configuration, check the service account mapping, inspect relevant permission bindings, and review sanitized error messages.
Related concepts: Kubernetes service accounts, IAM, workload identity, least privilege.
This note is useful even if you never mention the original project.
The goal is to retain the knowledge, not the incident details.
When you open Obsidian for the first time, create a vault.
A vault is simply a folder containing your notes.
Call it something like Technical Knowledge Base.
You don’t need an elaborate structure on day one. Start with something manageable.
Technical-Knowledge/
│
├── Inbox/
├── Concepts/
├── Technologies/
├── Troubleshooting/
├── Labs-and-Experiments/
├── Design-Patterns/
├── Career-and-Learning/
└── Daily-Notes/Here’s how to use each folder.
Inbox: Quick technical notes that you haven’t organized yet.
Concepts: Explanations of fundamental ideas such as DNS, TLS, containers, networking, IAM, and infrastructure as code.
Technologies: Notes organized around tools and platforms such as Terraform, Kubernetes, AWS, Azure, GCP, and GitHub Actions.
Troubleshooting: Generalized error patterns, diagnostic steps, root causes, and solutions.
Labs and Experiments: Things you have tested in your own environment or an authorized sandbox.
Design Patterns: Reusable architectural approaches, best practices, and technical decisions.
Career and Learning: Topics you want to master, certification preparation, and skill-development plans.
Daily Notes: A quick record of what you learned or explored during the day.
You can change this structure later. Don’t spend hours deciding where every note belongs.
If you are unsure, put it in the Inbox.
Let’s use a practical example.
Imagine you are working with Terraform and discover that your team needs to manage infrastructure state remotely.
You read the documentation, discuss the design, and learn about remote state storage and state locking.
Once you understand the concept, create a note called:
Terraform Remote State
Write the explanation in your own words.
# Terraform Remote State
## What is it?
Terraform state records the relationship between
Terraform configuration and the real infrastructure
managed by Terraform.
Remote state stores this information in a remote
backend instead of relying only on a local file.
## Why is it useful?
- Enables team collaboration
- Provides a shared state location
- Supports controlled access
- Can support state locking, depending on the backend
## Important things to understand
- State files may contain sensitive information.
- Access to the state must be restricted.
- Backend locking capabilities vary.
- State backups and recovery need to be considered.
## Practical learning
Experiment with a remote backend in a personal
sandbox environment.
## Related notes
- [[Terraform State]]
- [[Terraform Modules]]
- [[Infrastructure as Code]]
- [[Secrets Management]]
## Further questions
- How does state locking work?
- What happens if state is lost?
- How should state access be secured?This is already a useful note.
Notice what you have captured: the concept, why it matters, important considerations, and what to learn next.
You haven’t stored any client-specific information.
And you can reuse this note whenever you work with Terraform in the future.
Not every technical note should follow the same structure.
A concept you are learning, an error you are troubleshooting, and a command you want to remember are different things.
Here are four useful note types.
Use these when you want to understand something deeply.
Examples:
A simple structure:
# Concept Name
## What is it?
## Why does it matter?
## How does it work?
## Example
## Common mistakes
## Related conceptsThe most important part is explaining the concept in your own words.
If you cannot explain it simply, you may need to explore it further.
These are especially valuable for DevOps engineers, SREs, cloud engineers, and platform engineers.
Suppose you encounter a container that repeatedly restarts.
Instead of saving a production log or client-specific incident report, document the general troubleshooting pattern.
# Troubleshooting: Container Restart Loop
## Symptoms
A container repeatedly exits and restarts.
## Possible causes
- Application process exits unexpectedly
- Incorrect startup command
- Missing required configuration
- Dependency connection failures
- Memory limit exceeded
## Investigation steps
1. Inspect container status.
2. Review sanitized application logs.
3. Check the configured startup command.
4. Verify required environment variables.
5. Inspect resource limits and termination reasons.
## Lessons learned
Start by identifying why the process exits
before changing deployment configuration.
## Related notes
- [[Docker Container Lifecycle]]
- [[Kubernetes Pod Lifecycle]]
- [[Kubernetes Resource Limits]]This note becomes more valuable each time you improve it with another general lesson.
Over time, you can build a collection of troubleshooting playbooks for recurring technical problems.
Every IT professional has commands they use occasionally and forget later.
You might remember a command exists but forget the exact syntax.
Create a command reference.
# Useful kubectl Commands
## Inspect pods
kubectl get pods -A
## Describe a pod
kubectl describe pod <pod-name> -n <namespace>
## View recent logs
kubectl logs <pod-name> -n <namespace>
## Follow logs
kubectl logs -f <pod-name> -n <namespace>
## Important
Check the command options for your Kubernetes
version and your environment.
Never include production credentials or
confidential identifiers in saved examples.You can create similar notes for Linux, Git, Docker, Terraform, AWS CLI, Azure CLI, and networking tools.
Add a short explanation of when to use each command. That makes the note much more useful than a list of commands copied from a website.
Sometimes, reading about a technology isn’t enough. You need to try it.
For example, you might want to understand how Terraform handles a resource replacement or how Kubernetes performs a rolling update.
Create a note for the experiment.
# Lab: Kubernetes Rolling Update
## Objective
Understand how a Deployment replaces application pods.
## Environment
Local Kubernetes cluster.
## Experiment
Deploy a sample application and update its image.
## Observations
Record what happens to the old and new pods.
## What I learned
Explain the behaviour in your own words.
## Next experiment
Explore rollback and rollout history.Use your own environment or an explicitly authorized sandbox. Keep credentials and sensitive environment details out of your notes.
Lab notes are particularly helpful when you want to move beyond theoretical understanding.
This is one of the most useful features in Obsidian.
Suppose you have a note about Kubernetes ingress.
While writing it, you realize you also need to understand Services, DNS, TLS, and load balancing.
You can connect those notes using double square brackets.
An ingress controller routes external HTTP/HTTPS
traffic to Kubernetes Services.
Related concepts:
- [[Kubernetes Services]]
- [[DNS Resolution]]
- [[TLS Certificates]]
- [[Load Balancing]]When you click a link, Obsidian opens the corresponding note.
If the linked note doesn’t exist yet, you can create it when you need it.
This is useful because technical knowledge is interconnected.
Understanding Kubernetes ingress requires more than memorizing its definition. You may need to understand networking, DNS, certificates, and service discovery.
As you continue learning, your notes become a connected technical reference rather than a collection of isolated documents.
You don’t need to connect everything immediately. Add links when they help you understand a relationship.
Here is a habit that can make a real difference in your career.
Whenever you solve a technical problem or learn something new, ask yourself:
“What is the reusable technical lesson here?”
Imagine you have just completed a task involving a CI/CD pipeline.
Instead of writing:
“Fixed the pipeline issue for Project ABC.”
Write a note about the general problem:
Topic: Why a CI/CD pipeline may fail during container image publishing.
Then document how to distinguish these causes.
This creates a reusable troubleshooting guide.
The same approach works for infrastructure deployments, application performance, security scanning, cloud permissions, networking, monitoring, and incident investigation.
One important distinction: if the underlying lesson is based on proprietary client information or a restricted engagement, don’t transfer it into a personal vault without explicit authorization. Use independently written, generic examples based on public documentation or your own permitted experiments.
Your personal knowledge base should remain useful even when the original project is gone.
There is a difference between remembering a command and understanding why it works.
Your notes should help you move from one level to the next.
Consider learning Kubernetes.
At first, you might create a note explaining what a Deployment is.
Later, you might add:
Your original note becomes a starting point for deeper learning.
You can also add a section called Questions I still have.
For example:
Each question gives you a direction for your next learning session.
This is a simple way to turn day-to-day technical exposure into deliberate skill development.
A knowledge base is only useful if you can find information when you need it.
Obsidian has built-in search, so you can search for terms such as:
remote stateimage pullreadiness probeIAM permissionsTLS handshakeYou don’t need to remember which folder contains a note.
You can also use links and backlinks to move between related concepts.
For example, when reading your Terraform remote state note, backlinks can help you discover other notes that refer to it.
As your vault grows, search and linking become more useful than maintaining a complicated folder hierarchy.
If you repeatedly write the same kind of note, use Obsidian’s built-in Templates core plugin.
You can create a reusable template for technical concepts:
# {{title}}
## Summary
## How it works
## When to use it
## Example
## Common mistakes
## Security considerations
## Related notes
## Questions to exploreCreate a separate template for troubleshooting:
# Troubleshooting: {{title}}
## Symptoms
## Possible causes
## Diagnostic steps
## Generic solution or workaround
## Why it works
## Prevention
## Related notesYou don’t need to fill every section.
If you only have time to write three lines, write three lines.
The template is there to help you think, not to force you to complete paperwork.
You don’t need to spend an hour every day maintaining Obsidian.
Try this routine.
During work or learning
When you discover a useful concept, write a quick note. Capture the technical idea while it is fresh.
After solving a problem
Spend a few minutes identifying the underlying cause, the diagnostic approach, and the reusable lesson. Remove client-specific details and follow your information security policies.
At the end of the day
Review your Inbox. Expand only the notes that are worth keeping.
Once a week
Spend 15–20 minutes connecting related notes, revisiting unanswered questions, and selecting the next technical topic to learn.
A small habit is more sustainable than a complicated system.
Even two or three useful technical notes per week can add up to a substantial personal reference library over time.
Because this is a personal technical knowledge base, a few practices are worth following.
Obsidian’s local-first design gives you control over your files, but security still depends on how you store, sync, back up, and access them.
For most personal learning, a straightforward local vault with an appropriate backup is a good place to start.
Working in IT means constantly learning new things.
But learning something once and being able to use it confidently two years later are very different things.
A personal technical knowledge base helps bridge that gap.
You document the concepts you understand, the commands you frequently use, the problems you know how to investigate, and the experiments that teach you something new.
You connect these notes and revisit them when you need to.
Over time, your vault becomes a record of your technical growth.
You don’t need to document every task. You don’t need hundreds of plugins. You don’t need a perfect system.
Start with one note about something you learned this week.
Explain it in your own words. Add a practical example. Link it to a related concept. Write down what you still don’t understand.
Then do it again next week.
The objective isn’t to collect more information. It’s to become the kind of engineer who understands more, solves problems faster and doesn’t have to relearn the same things repeatedly.
And that’s what makes a personal technical knowledge base worth building.
Linux has a convenient feature of running cronjob which will get executed at the correct…
As famous Tamil poet Auvaiyar said "Katradhu Kai Mann Alavu, Kallathathu Ulaga Alavu" which is…
Terraform Cheatsheet with pdf. You can download Terraform Cheatsheet pdf with all Terraform CLI commands…
I was planning to do Terraform certification a long time ago. I have worked on…
As a user of both of these services has got multiple benefits with both of…
You need not memorize these important docker commands. Repeated usage will make it easy for…
This website uses cookies.