DevOps Cheat Sheet 2026: CALMS, CI/CD, IaC, Containers, Observability

🚀 30 Days DevOps Revision Challenge – Day 13 Day 13 of my DevOps revision challenge — and today was a big step forward. After revising Terraform modules yesterday, today I worked on a complete module-based project, where I tried to bring multiple concepts together in a structured and production-like way. 📌 Day 13 Focus: Terraform Modules Project (End-to-End Understanding) Today I didn’t just revise — I implemented and connected multiple Terraform concepts into one project. 🧩 Core Concepts I Worked On 🔹 Provider & Version Constraints Defined providers properly in terraform.tf Ensured version control for stability and consistency 🔹 Variables with Validation Used variables.tf with validation rules Made inputs more controlled and error-free 👉 This helps avoid wrong configurations in real projects 🔹 EC2 + Security Groups + Key Pairs Created EC2 instances Configured security groups for access control Managed key pairs for secure login 🔹 User Data (Bootstrapping) Used user_data + shell script Automatically configured instance (like installing Nginx) 👉 This is real automation — infra + setup together 🔹 S3 with Versioning & Encryption Created S3 bucket Enabled versioning and encryption 👉 Important for data safety and backup 🔹 DynamoDB Tables Used for state locking Ensures no conflict in team environment 🔹 Outputs Extracted useful values like IPs, resource IDs Helps in integration and debugging 🔥 Main Highlight: Reusable Modules Project 👉 This was the most important part today Created a proper module-based structure (aws_module_project/) Broke infrastructure into reusable components Used modules inside main configuration Built a multi-environment setup using modules 👉 Simple understanding: Instead of writing everything in one file → I created clean, reusable, scalable building blocks 🔁 Advanced Concepts Covered for_each & dynamic blocks → flexible resource creation Lifecycle rules → control resource behavior Import existing resources → manage already created infra Refactoring (moved block) → restructure without breaking state Check blocks (validation/assertions) → ensure correctness Safe resource removal → prevent accidental deletion Terraform test framework (intro) → testing infra code 🔗 Project Link (GitHub) Here is the project where I implemented all these concepts: 👉 https://lnkd.in/gdvvS6Xx 💡 Key Takeaway Today I realized: 👉 Terraform is not just about writing configs 👉 It’s about designing scalable, reusable, and safe infrastructure systems Modules + state + validation + structure = 🔥 Production-level DevOps mindset 🎯 What’s Next Improve this project further Integrate with CI/CD (Jenkins) Move towards Docker & Kubernetes This was one of the most complete learning days so far 🚀 From small concepts → to full project thinking 💯 #DevOps #30DaysChallenge #Terraform #Modules #AWS #InfrastructureAsCode #LearningInPublic #Consistency #TechJourney

Automation and Monitoring are the two engines that keep the DevOps cycle running. One builds the speed, the other ensures you don't crash. 🏎️💨 If you are looking to master the "Ops" in DevOps in 2026, you need a clear path. We’ve moved past simple cron jobs and basic alerts. Today, it’s about Autonomous Recovery and Full-Stack Observability. The image below is your 2026 Automation & Monitoring Roadmap. Here is the high-level breakdown you need to know: Level 1: The Automation Foundation (Build & Deploy) 🔹 CI/CD Evolution: Move beyond Jenkins. Master GitHub Actions, GitLab CI, or ArgoCD for GitOps-based deployments. 🔹 Infrastructure as Code (IaC): If it isn't in Terraform or Pulumi, it doesn't exist. Automate your cloud environment so it's repeatable and version-controlled. 🔹 Configuration Management: Using Ansible or Chef to ensure your fleet of servers stays consistent without manual login. Level 2: The Monitoring Strategy (Watch & Detect) 🔹 The Metrics Layer: Prometheus + Grafana. You need to see your CPU, RAM, and Latency in real-time. 🔹 Log Aggregation: ELK Stack (Elasticsearch, Logstash, Kibana) or Loki. You can't debug what you can't search. 🔹 Health Checks: Implementing automated "Synthetics" that test your user journeys every minute, not just "is the server up." Level 3: The 2026 Edge (Observe & Automate) 🔹 From Monitoring to Observability: It’s not just "red/green" anymore. Use OpenTelemetry to trace a single request through 10 different microservices. 🔹 AIOps & Self-Healing: Using scripts that automatically trigger a "Restart" or "Scale Up" event based on threshold breaches before an engineer is even paged. 🔹 ChatOps: Bringing your automation into Slack/Teams so you can deploy or roll back with a single command. The Goal: A system that tells you why it broke, not just that it broke. 📌 SAVE THIS ROADMAP to guide your learning or to show your team what "Modern Ops" looks like. Which tool is a "Must-Have" in your stack this year? Prometheus, Terraform, or something else? Let’s talk below! 👇 7000+ Courses = https://lnkd.in/gTvb9Pcp 4000+ Courses = https://lnkd.in/g7fzgZYU Telegram = https://lnkd.in/gvAp5jhQ more - https://lnkd.in/ghpm4xXY Google AI Essentials → https://lnkd.in/gby_5vns AI For Everyone → https://lnkd.in/grgJGawB Google Data Analytics → https://lnkd.in/grBjis42 Google Project Management: → https://lnkd.in/g2JEEkcS Google Cybersecurity → https://lnkd.in/gdQT4hgA Google Digital Marketing & E-commerce → https://lnkd.in/garW8bFk Google UX Design → https://lnkd.in/gnP-FK44 Microsoft Power BI Data Analyst → https://lnkd.in/gCaHF8kT Machine Learning → https://lnkd.in/gFad6pNE Foundations: Data, Data, Everywhere → https://lnkd.in/gw4BwhJ2 IBM Data Analyst → https://lnkd.in/g3PsGrKy IBM Data Science → https://lnkd.in/gHYZ3WKn Deep Learning → https://lnkd.in/gaa5strv #DevOps #Automation #Monitoring #SRE #CloudEngineering #Terraform #Grafana #TechRoadmap2026

Over the past 6 years navigating the DevOps ecosystem, I’ve seen teams wrestle with the same recurring dilemma: Build vs. Buy? Do we engineer a custom in-house tool, or do we adopt a ready-to-use solution? There is no universal right answer, but having been in the trenches with both, here is my perspective on how they truly stack up. 🛠️ Effort & Learning Curve In-House: High upfront engineering effort. The learning curve isn't just about using the tool—it's about building, patching, and maintaining it. It demands dedicated developer bandwidth that is diverted from the core product. Ready-to-Use: Plug-and-play functionality. The initial effort is significantly lower, and the learning curve focuses strictly on user adoption and integration rather than underlying system architecture. 📈 Success Rate & Scaling In-House: Custom tools are often victims of their own success. They work beautifully for the small team that built them, but scaling them as the company grows often leads to brittle infrastructure, operational bottlenecks, and heavy technical debt. Ready-to-Use: These are engineered to scale. The immediate success rate is generally higher because the vendor handles the backend heavy lifting. However, be warned: at hyper-scale, these tools can become prohibitively expensive. ⚖️ The Trade-Offs In-House Advantages: Ultimate flexibility, zero vendor lock-in, and a solution tailored perfectly to your organization's specific edge cases. In-House Drawbacks: "You build it, you run it." The maintenance burden is heavy. Security, compliance, and onboarding documentation become your sole responsibility. Ready-to-Use Advantages: Faster time-to-market, dedicated support, regular feature updates, and out-of-the-box compliance. Ready-to-Use Drawbacks: Feature bloat, vendor lock-in, and sometimes having to adapt your internal workflows to fit the tool’s limitations. 💡 Things to Keep in Mind (My Takeaways) Total Cost of Ownership (TCO): "Free" open-source or custom-built is never truly free. Always factor in the engineering hours spent maintaining and troubleshooting the tool versus the predictable cost of paying a vendor. Core Competency: Is your business selling this tool? If not, why dedicate your best engineers to building it? Focus your engineering power on delivering value to your customers. The Pragmatic Approach: Start with ready-to-use solutions to gain momentum. Only pivot to building in-house when off-the-shelf options fundamentally fail to meet your unique, complex requirements. What has your experience been? Do you default to building custom solutions, or do you prefer leveraging off-the-shelf tools? Let’s discuss below!…👇 #DevOps #SRE #PlatformEngineering #TechLeadership #BuildVsBuy #SoftwareEngineering #TechDebt

🚀 Day 1: Making Kubernetes Fun | My DevOps Transition Begins I’ve been working in middleware, handling systems, troubleshooting issues, and keeping things running. But lately, I’ve been asking myself — what’s next? 👉 The answer: DevOps And every DevOps journey somehow leads to one place — Kubernetes. To be honest, Kubernetes always felt overwhelming. Too many components, too many YAML files, too much going on. So I decided to change my approach: 💡 Instead of fearing Kubernetes, I’ll make it fun. ⸻ 🔹 Day 1 Learning: Helm Charts (Deep Dive) Today I explored Helm, the package manager for Kubernetes — and honestly, it made things 10x simpler. 📦 What exactly is Helm? Helm helps you define, install, and manage Kubernetes applications using Helm Charts (reusable templates). ⸻ 📁 Structure of a Helm Chart: • Chart.yaml → Metadata (name, version, description) • values.yaml → Default configurable values • templates/ → Kubernetes YAML templates (Deployment, Service, etc.) • charts/ → Subcharts (dependencies) ⸻ ⚙️ How Helm Actually Works: Helm uses a templating engine (Go templates). Instead of hardcoding values in YAML, you use placeholders like: replicas: {{ .Values.replicaCount }} And define actual values in values.yaml. 👉 This means: • Same chart can be reused across dev, staging, prod • Just change values, not the entire YAML ⸻ 🚀 Key Helm Commands: • helm install my-app ./chart → Deploy application • helm upgrade my-app ./chart → Update application • helm rollback my-app 1 → Rollback to previous version • helm uninstall my-app → Remove deployment ⸻ 🔁 Concept of Releases: Every time you install a chart, Helm creates a release. 👉 Think of a release as: • A running instance of your chart • With its own version history • Easy rollback support ⸻ 🔐 Handling Secrets in Helm: • Avoid hardcoding sensitive data • Use tools like: • Kubernetes Secrets • Helm Secrets plugin • External secret managers (AWS/GCP Vaults) ⸻ 💡 Why Helm is a Game-Changer: • Eliminates repetitive YAML writing • Standardizes deployments • Enables versioning of infrastructure • Makes CI/CD pipelines cleaner ⸻ 💭 My takeaway: Kubernetes starts feeling easier when you stop writing everything from scratch and start using the right tools. ⸻ 📌 I’m starting this #100DaysOfDevOps-style journey where I’ll share one concept every day — simplified. If you’re also learning or planning to switch to DevOps, let’s connect and grow together 🤝 ⸻ #Kubernetes #Helm #DevOps #CloudComputing #SRE #LearningInPublic #CareerSwitch

From DevOps Engineer to Systems Maestro: Orchestrating AI, Lean, and Governance We spent years automating pipelines. Now we're automating decisions. And that changes everything. I've been thinking about this a lot lately. DevOps used to mean building reliable infrastructure, keeping deployments clean, making sure things didn't break at 2am. That was the job. But something has quietly changed underneath us, and I think a lot of engineers haven't fully named it yet. The environments we run today are more automated than ever, and still surprisingly fragile. Pipelines fail in ways nobody predicted. Alerts pile up until nobody trusts them. Systems scale faster than the processes meant to govern them. We automated the execution, but never the judgment. And that gap is where things get interesting. AI agents are starting to fill that gap. Not in a theoretical, conference-talk way. In a real, production way. An agent detects abnormal latency. Another correlates logs. Another opens an incident. Another executes a rollback. In a mature Kubernetes environment, that entire chain can happen without a human making a single explicit decision. Which is remarkable. And also a little terrifying. Because AI agents don't just scale operations. They scale decisions. Including bad ones. This is where Lean Six Sigma becomes genuinely relevant to modern DevOps, not as a certification to put on a resume, but as a practical philosophy. The goal was never to eliminate errors entirely. It was to reduce variability until errors become statistically negligible. Applied to DevOps, that means stable incident response times, consistent deployment behavior, less noise and more signal. Without that foundation, you're not deploying intelligent systems. You're deploying fast chaos. Governance matters more than people want to admit. ITIL and ISO frameworks aren't bureaucracy for its own sake. They're the answer to a question autonomous systems force us to ask: who audits the agents? If an AI makes a bad call at 3am with no audit trail, no defined workflow, no accountability structure, you don't have an intelligent system. You have an untraceable one. What I keep coming back to is the idea of the maestro. The DevOps engineer's role is shifting from execution to orchestration. You're not playing the instruments anymore. You're deciding what the music should sound like, setting the boundaries, listening for when something's off, and knowing when the arrangement needs to change. The agents execute. You decide what needs to evolve. That's a harder job than it sounds. It requires knowing your systems deeply enough to trust them, and well enough to know when not to. The companies that will pull ahead aren't the ones with the most automations. They're the ones with the best orchestration. There's a real difference between the two . So the question I'd leave you with is the one I keep asking myself: are you still building pipelines, or are you starting to conduct systems?

Anthropic just shipped Routines inside Claude Code. Your DevOps engineer just got a lot less busy. 😅 Here's why this is a bigger deal than people realize: Every team I've worked with has the same problem: "We know what to automate. We just never get around to building it." Because building automations always meant: → Writing scripts → Setting up servers → Managing cron jobs → Debugging at 2am when something silently breaks 💀 Routines just eliminated all four. Here's the evolution in one timeline: 1️⃣ You wrote bash scripts. Taped them to a cron job. Prayed. 2️⃣ No-code tools arrived. Less code, but now you're debugging Zapier flows with 43 steps. 3️⃣ AI started writing the automation code for you. But you still needed somewhere to run it. 4️⃣ Now: you describe the task. Claude writes it, hosts it, runs it on schedule, and course-corrects when something changes. The infrastructure layer just disappeared. 🧹 That's the real shift. Not "AI writes code faster." It's that the gap between describing what you want and having it running in production just went to zero. We use n8n, Claude, and custom automation workflows daily at Devs Core — it's the backbone of how we build and maintain software for our startup clients. Routines changes things for us in two ways: 🔹 For our clients: We built an automated member onboarding portal for an architectural institution managing 10,000+ members. That project took 4 months and a 6-person team. With Routines, the recurring parts of that system — nightly data cleanup, member status checks, notification triggers — could be described in plain English and running the same day. That's weeks of dev time saved for our clients. 🔹 For our team: We already use AI-driven practices to monitor and maintain client software post-deployment. Routines means we can set up self-correcting workflows — deployment error checks, bug triage across repos, automated code reviews against our team checklists — without spinning up additional infrastructure. Our maintenance gets faster without adding headcount. 🚀 This is what excites me most: for teams like ours that build automation workflows for startups, Routines doesn't replace what we do. It accelerates it. Less time on infrastructure plumbing. More time solving the actual business problem. 🎯 The limits right now: → Pro plan ($20/mo): 5 runs/day → Max plan ($100/mo): 15 runs/day → Team/Enterprise: 25 runs/day It's early. It's a research preview. But the direction is unmistakable. We're moving from "tools that help you build automations" to "tools that ARE the automation." If you're a startup founder wondering how this fits into your tech stack — or if you're already experimenting with Routines — drop a comment. Would love to hear what workflows you're building. #claudecode #routines #automation

Everyone is talking about AI in DevOps right now. But I think a lot of the discussion is happening at the wrong level. To me, the interesting question is not whether AI can generate a Dockerfile or help write a Kubernetes manifest. That is nice, of course. But it is not the part that matters most. The more interesting question is this: can AI help us make better decisions when we run containerized systems in the real world? For example, can we use historical Prometheus metrics to predict load and scale a service before latency goes up and before users start to feel the problem? That is where AI starts to become truly useful. Not as decoration. Not as magic. And not as a replacement for good engineering. It becomes useful when it builds on a solid foundation. If your container images are badly designed, your deployment process is fragile, your observability is weak, or your Kubernetes setup is not well understood, then adding AI on top will not fix that. It will only add another layer of complexity. That is one of the ideas behind my book, The Ultimate Docker Container Book, Fourth Edition. In the book, I do not jump straight into AI. I start with the basics and build from there. We begin with containers, Docker, images, volumes, configuration, debugging, testing, and day-to-day productivity. From there, we move into networking, Docker Compose, logging, monitoring, security, Kubernetes, cloud deployment, and troubleshooting in production. Only after that do we look at AI and automation. This is important to me, because AI in DevOps only makes sense when the reader first understands the platform it is supposed to improve. And when the book gets to AI, it stays practical. It includes hands-on work around AI and automation in DevOps, such as building a predictive autoscaler, learning from Prometheus metrics, deploying the supporting pieces into Kubernetes, and automating model refresh with Argo Workflows. The book also covers many of the things teams really struggle with in practice. It looks at how to write better Dockerfiles, how to use multi-stage builds, how to scan images and verify where they come from, how to harden containers, how to manage secrets, how to work effectively with Docker Compose, and how to understand Kubernetes objects such as Pods, Deployments, Services, probes, rollouts, and security controls. It also covers observability with Prometheus, Grafana, OpenTelemetry, and Jaeger, as well as running applications on AKS, EKS, and GKE. So this is not a book just about commands. It is a book for people who want to understand how to build, ship, run, secure, monitor, and improve containerized applications in a professional way. And that is exactly why AI belongs in it. Because AI becomes useful only when the engineering underneath it is already solid. That is where the real value starts. #Docker #Kubernetes #AI #DevOps #PlatformEngineering #Containers #Observability #Automation #CloudNative

🔧 Lab Title: 24 - Demo project: Deploy Microservices with Helmfile 🚀 Project Steps PDF Your Easy-to-Follow Guide:https://lnkd.in/gVGaXYRD 🔗 GitLab Repo Code:https:https://lnkd.in/g8dcu7yz 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I automated the deployment and cleanup of multiple Kubernetes microservices using Helm, shell scripts, and Helmfile. I explored Helm chart management, declarative deployments, and Kubernetes resource verification. This lab focused on streamlining multi-service deployment with automation for faster, error-free CI/CD pipelines. ⚙️📦 Tools Used: Helm: For packaging and deploying microservices. Shell scripting (bash): Automated install/uninstall commands. Helmfile: Managed multiple Helm releases declaratively. kubectl: Verified pod and service statuses. Skills Gained: 🚀 Automated multi-service Helm deployments with shell scripts. 🗂️ Used Helmfile for centralized release management. 🔍 Verified and troubleshot Kubernetes deployments efficiently. Challenges Faced: 🔐 Setting correct script permissions for automation. ⚙️ Managing Helm values and overrides in Helmfile. 🧹 Creating reliable uninstall scripts to keep cluster clean. Why It Matters:  This lab teaches key DevOps automation skills, showing how Helm, scripting, and Helmfile simplify Kubernetes microservice management. Mastering these tools enables faster, consistent, and scalable deployments—essential for modern cloud-native DevOps roles. 🌐🔥 📌 hashtag#DevOps hashtag#CI_CD hashtag#Automation hashtag#Kubernetes hashtag#Helm hashtag#Helmfile hashtag#CloudNative 🚀 Stay tuned!  Next: Project 11 - Kubernetes on AWS - EKS 🔥

🔄 DevOps Day 3 — The full pipeline finally clicked. Here's how code actually travels from a developer's laptop to your phone screen. Everything starts with 4 questions: Who gives the business? → Client Who builds the app? → Developers Who ships it to the world? → DevOps Team Who uses it? → Users Simple. But what happens inside step 3 is where DevOps lives. ───────────────────────────── 🧰 The DevOps pipeline — tool by tool: 📦 GitHub — Code repository Developers don't hand over code on a USB. They push it to GitHub. DevOps pulls from there. It's the shared source of truth for the entire team. No GitHub = no collaboration, no version history, no safety net. 🔍 SonarQube — Code quality test Before deploying, we check the code. Not for logic — for quality. Are there hardcoded passwords? Duplicate lines? Bugs hiding in plain sight? SonarQube scans the code, flags issues, and even suggests fixes. The DevOps engineer shares the report with developers. They fix it. Simple. ⚙️ Maven — Build tool Code alone can't run on a server. It needs dependencies (libraries, packages, frameworks). Maven bundles the code + all dependencies into one deployable package. Think of it like zipping multiple folders before sending via email — everything in one place, nothing missing. 🗄️ Artifact (Nexus / JFrog) — Ready-to-deploy storage Sometimes you build early but deploy later. That built package is called an artifact — "ready to deploy, just waiting." Artifact tools store it safely until you need it. 🏗️ Terraform — Infrastructure creation Before deploying anything, the server must exist. Terraform creates cloud infrastructure (servers, databases, networks) using code — on AWS, Azure, or GCP — in minutes. ───────────────────────────── 🔄 CI/CD — The part everyone gets confused about: CI = Continuous Integration — automatically picks up new code from GitHub and runs the pipeline. CD (Delivery) = Builds + tests → stores as artifact → you deploy manually later. CD (Deployment) = Builds + tests → deploys to server automatically, no human needed. The difference? One stops at "ready." The other goes all the way to "live." Big sale tomorrow? Use CD Delivery — build now, deploy exactly when the offer goes live. Ongoing daily changes? Use CD Deployment — push code, it's live in minutes. 🔑 Today's realization: DevOps isn't one tool. It's a pipeline where every tool solves one specific problem in the journey from code → server → user. Remove any one tool and the chain breaks. Day 4 tomorrow — Docker and Kubernetes. The big ones. 🐳☸️ #DevOps #CICD #GitHub #SonarQube #Maven #Terraform #Jenkins #GitLabCI #CloudComputing #AWS #AzureCloud #GCPCloud #MultiCloud #CloudEngineer #DevOpsEngineer #DevOpsJourney #LearnDevOps #DevOpsCommunity #DevOpsPipeline #LearningInPublic #100DaysOfCode #TechLearning #Day3 #CareerJourney #Automation #Infrastructure #Containerization #Artifact #BuildTools #Hiring #TechJobs #OpenToWork #ITCareer #Fresher #TechIndia #HyderabadTech

🚀 DevOps Roadmap – A Practical Guide for Engineers Sharing a structured visual roadmap that every aspiring DevOps Engineer should follow to build strong fundamentals and advanced expertise. This roadmap covers essential domains: 🔹 Linux & Operating Systems (File System, Permissions, Processes, Shell Scripting, Networking Fundamentals) 🔹 Version Control (Git Basics, Branching & Merging, Pull Requests, GitHub/GitLab Workflows) 🔹 Programming & Scripting (Bash, Python, YAML/JSON, APIs, Basic Data Structures) 🔹 CI/CD (Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Build & Release Strategies) 🔹 Cloud Platforms (AWS / Azure / GCP Basics, IAM, Networking, Storage, Monitoring) 🔹 Containers (Docker, Dockerfile, Docker Compose, Image Optimization, Container Registry) 🔹 Container Orchestration (Kubernetes Architecture, Pods, Services, Deployments, Helm, Scaling) 🔹 Infrastructure as Code (IaC) (Terraform, CloudFormation/ARM, Bicep, State Management, Modules) 🔹 Security – DevSecOps (SAST/DAST, Vulnerability Scanning, Secrets Management, Compliance) 🔹 Monitoring & Logging (Prometheus, Grafana, ELK Stack, Alerting Strategies) 🔹 Advanced Concepts (Microservices, GitOps, Blue-Green Deployment, Canary Releases, SRE) Mastering these areas helps engineers design scalable, automated, secure, and production-ready systems. Whether you’re starting your DevOps journey or strengthening your fundamentals, this roadmap can guide your learning path step by step. 7000+ Courses = https://lnkd.in/gTvb9Pcp 4000+ Courses = https://lnkd.in/g7fzgZYU Telegram = https://lnkd.in/gvAp5jhQ more - https://lnkd.in/ghpm4xXY Google AI Essentials → https://lnkd.in/gby_5vns AI For Everyone → https://lnkd.in/grgJGawB Google Data Analytics → https://lnkd.in/grBjis42 Google Project Management: → https://lnkd.in/g2JEEkcS Google Cybersecurity → https://lnkd.in/gdQT4hgA Google Digital Marketing & E-commerce → https://lnkd.in/garW8bFk Google UX Design → https://lnkd.in/gnP-FK44 Microsoft Power BI Data Analyst → https://lnkd.in/gCaHF8kT Machine Learning → https://lnkd.in/gFad6pNE Foundations: Data, Data, Everywhere → https://lnkd.in/gw4BwhJ2 IBM Data Analyst → https://lnkd.in/g3PsGrKy IBM Data Science → https://lnkd.in/gHYZ3WKn Deep Learning → https://lnkd.in/gaa5strv Writing in the Sciences → https://lnkd.in/gHewehvu Neural Networks and Deep Learning → https://lnkd.in/g53wXSHA Google Advanced Data Analytics → https://lnkd.in/gnG-SMAA Google IT Support → https://lnkd.in/gb5EdRwg Google IT Automation with Python → https://lnkd.in/gm2XB6KC Foundation of User Experience (UX) Design → https://lnkd.in/gjGctKBY Meta Front-End Developer → https://lnkd.in/gE8rZ4m9 Indigenous Canada → https://lnkd.in/gu3y2X_p Data Analysis with R Programming → https://lnkd.in/gbAH3JYc #DevOps #CloudComputing #SRE #Automation #Kubernetes #Docker #Terraform #CI_CD #Learning #Tech