DEV Community: Sherdil IT Academy

How We Actually Calculate Our 95% Certification Success Rate

Sherdil IT Academy — Fri, 30 Oct 2026 07:56:20 +0000

A "95% success rate" is a meaningless number without knowing what it's a percentage of. 95% of everyone who enrolled? 95% of everyone who finished the course? 95% of everyone who actually sat the exam? Each of those denominators tells a wildly different story, and most institutes that advertise a headline number never show you which one they used. So here's ours, with the actual calculation shown, not just the final figure.

The calculation, in the open

def success_rate(enrolled, completed_course, sat_exam, passed_exam):
    """
    Returns three different percentages depending on which denominator
    you choose, because they are not interchangeable, and quoting
    the most flattering one without saying which it is isn't honest.
    """
    return {
        "pass_rate_of_sat_exam":   round(passed_exam / sat_exam * 100, 1) if sat_exam else None,
        "pass_rate_of_completers": round(passed_exam / completed_course * 100, 1) if completed_course else None,
        "pass_rate_of_enrolled":   round(passed_exam / enrolled * 100, 1) if enrolled else None,
    }

# A real cohort's numbers (one certification track, one enrollment period)
cohort = success_rate(
    enrolled=120,
    completed_course=104,   # some drop out before finishing, for reasons unrelated to the program
    sat_exam=98,            # some who finish choose to delay their attempt
    passed_exam=93,
)
print(cohort)

{'pass_rate_of_sat_exam': 94.9, 'pass_rate_of_completers': 89.4, 'pass_rate_of_enrolled': 77.5}

Why the gap between these numbers matters

Three defensible numbers, from the exact same cohort: 94.9%, 89.4%, 77.5%. All three are technically true. Only one of them, the pass rate of people who actually sat the exam, measures what most people assume a "success rate" measures: if you prepared and sat the exam with us, did you pass? The other two numbers answer different, also legitimate, questions, but they are not what the phrase "certification success rate" implies to a reader, and quoting the highest one without saying which denominator it uses is the exact pattern worth being suspicious of anywhere else you see this claim.

The headline "95%" figure on our own site uses the sat-exam denominator, averaged across multiple cohorts and certification tracks rather than a single one, which is why it differs slightly from the single-cohort example above. The point of showing this calculation isn't to argue our specific number, it's to show the method, so you can ask any institute, including us, to show theirs the same way.

What a dishonest version of this looks like

# The flattering-but-misleading version: pick whichever denominator is smallest,
# and never mention which one you used
misleading_number = passed_exam / sat_exam * 100  # looks the strongest, stated with no context

This is not a hypothetical. It is the single most common pattern behind inflated certification claims: a correct calculation, against a denominator chosen for how good it looks rather than for what it actually measures, presented without the denominator ever being named.

The question worth asking anyone who quotes you a number

"Is that out of everyone who enrolled, everyone who finished, or everyone who sat the exam?" Any institute with a real, verifiable number can answer immediately, because they calculated it once and know exactly what it measures. An institute that has to think about the question, or that gives you a vague restatement of the original percentage instead of naming a denominator, is telling you something worth paying attention to.

This is one specific piece of a larger pattern worth checking before you commit to any training provider, not just on the success-rate claim but across every claim on their homepage. If you're comparing institutes more broadly, here's a complete framework and scoring method for evaluating cloud training providers in Pakistan, built around exactly this kind of verifiable evidence rather than marketing copy.

I wrote up the complete picture of what our certification success rate actually measures, how it's tracked, and why we publish the methodology rather than just the headline number, over here: Sherdil IT Academy: Why a 95% Certification Success Rate Matters.

Has an institute ever actually shown you their denominator when you asked? What happened? Drop it in the comments. 👇

The One GCP IAM Feature AWS and Azure Still Don't Match

Sherdil IT Academy — Mon, 26 Oct 2026 10:45:23 +0000

Most IAM concepts translate cleanly across AWS, Azure, and GCP: roles, policies, scopes, the vocabulary differs but the shape is the same. One GCP feature genuinely does not have a clean native equivalent on the other two: IAM Conditions, which let you attach an expression directly to a role binding so access is granted only when that expression evaluates true. Here's what it actually does, and when it's worth reaching for.

The problem it solves

Standard IAM grants access until someone remembers to revoke it. A contractor given temporary project access, an on-call engineer who needs elevated permissions only during an incident, a role that should only apply from a specific resource, all of these normally require either a manual revocation step someone has to remember, or a separate automation pipeline to enforce the restriction. IAM Conditions build the restriction into the binding itself.

How it works

# Grant a role that automatically expires, no cleanup job required
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="user:contractor@example.com" \
  --role="roles/storage.objectViewer" \
  --condition='expression=request.time < timestamp("2026-11-30T00:00:00Z"),title=contractor-access,description=Expires end of Nov 2026'

That binding simply stops granting access after the timestamp passes. No cron job, no reminder, no manual revoke step that someone forgets during a busy week.

# Grant access scoped to a specific resource pattern, not the whole project
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="serviceAccount:ci-deploy@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/staging-"),title=staging-only,description=CI can only touch staging buckets'

This is the pattern that matters most in practice: a CI/CD service account that can write to staging buckets but is structurally incapable of touching anything named prod-*, enforced by IAM itself rather than by hoping the pipeline code never has a bug.

Checking what's actually in effect

gcloud projects get-iam-policy YOUR_PROJECT_ID --format=json | \
  jq '.bindings[] | select(.condition != null)'

Auditing conditional bindings is itself a skill worth having, because a condition silently narrows or time-bounds an otherwise broad-looking role, and a policy review that only reads role names without reading conditions will miss that nuance entirely.

Why this is worth knowing even if GCP isn't your main cloud

AWS has some comparable building blocks (IAM policy conditions using context keys, time-based tags) and Azure has Conditional Access for identity sign-in scenarios, but neither bakes an arbitrary expression directly into a standard role binding at the resource-access layer the way GCP does. If your work is mostly AWS or Azure today, understanding this pattern is still useful: it's a clean mental model for "access that should not need a human to remember to revoke it," and recognizing where your current cloud makes you build that manually is a good prompt to go build it.

Whichever cloud you end up specializing in, access-expiry and least-privilege patterns like this one show up constantly on the hands-on portion of most cloud certification exams. If Azure is the direction you're actually training toward, the complete AZ-104 cost and preparation guide, including a lab plan built around exactly this kind of IAM scenario, is the place to pick that up.

I put together the complete 2026 picture for GCP certification in Pakistan, exam costs, job roles, and a realistic career path, over here: GCP Certification Pakistan 2026: Costs, Jobs, Career Path.

Have you used conditional IAM bindings for something other than time-bound access? What was the use case? Drop it in the comments. 👇

I Learned Two Cloud Topics Two Ways. One-Month Retention Test.

Sherdil IT Academy — Fri, 23 Oct 2026 06:27:19 +0000

"Hands-on labs beat passive video" is repeated constantly in cloud training advice, including by me, in other posts, without ever being shown. So I ran a small test on myself: two cloud topics I had never touched before, roughly matched for difficulty, the same total study time on each, one learned entirely through video content and notes, the other entirely through hands-on labs. Then I quizzed myself at one week and again at one month, honestly, before looking anything up.

Caveat up front: this is a sample size of one, run on myself, with all the bias that implies. It is not a controlled study. Treat it as one data point, not proof, and notice whether the pattern matches your own experience rather than taking the numbers as universal.

The setup

# Two topics, matched for approximate difficulty, 6 hours of study time each
topics = {
    "Azure Virtual Networking":   {"method": "video_course", "hours": 6},
    "Azure Storage & Access Control": {"method": "hands_on_labs", "hours": 6},
}

# Self-quiz: 20 practical questions per topic, scored honestly, no lookups
# Scored at two checkpoints: 1 week after study, 1 month after study
results = {
    "Azure Virtual Networking":      {"week_1": 15, "month_1": 8},   # out of 20
    "Azure Storage & Access Control": {"week_1": 17, "month_1": 15}, # out of 20
}

for topic, scores in results.items():
    decay = scores["week_1"] - scores["month_1"]
    decay_pct = decay / scores["week_1"] * 100
    print(f"{topic}: {scores['week_1']}/20 -> {scores['month_1']}/20  ({decay_pct:.0f}% decay)")

Azure Virtual Networking: 15/20 -> 8/20  (47% decay)
Azure Storage & Access Control: 17/20 -> 15/20  (12% decay)

What actually happened

The video-learned topic started slightly weaker at the one-week mark, which already hints at something, and then fell off a cliff by one month: nearly half of what I thought I knew at week one was gone a month later. The lab-learned topic started stronger and barely moved. By the one-month mark the gap was not subtle: 8 out of 20 versus 15 out of 20 on topics I had rated myself equally confident in at the one-week checkpoint.

Why this probably isn't a fluke, even at n=1

The honest mechanism, as far as I can tell from paying attention to my own recall during the quiz, was not that the video content was lower quality. It was that I could recall facts about networking concepts without being able to reconstruct how to do anything with them, while the lab-learned storage and access control material came back as procedure, not facts. Procedural memory built from actually typing commands and watching them succeed or fail seems to survive a month in a way that passively-absorbed facts do not. That matches a decent amount of general learning-science literature on the difference between declarative and procedural memory, for whatever that is worth here.

What I'd actually change based on this

Not "never watch another video," that would overcorrect past what one data point supports. What I would change: use video for the initial orientation to a new concept, the first pass that gets the vocabulary and the shape of the problem into your head, then move to hands-on labs as fast as possible for anything you actually need to retain past a week. The video-only topic above was pure video with no lab component at all, which is probably the worst version of the comparison, and a more realistic recommendation is video-to-orient, labs-to-retain, not one or the other exclusively.

If you want to see what this looks like applied to a real exam rather than an isolated topic, the complete lab-first study plan I built for the AZ-104, six weeks of nothing but Azure CLI commands mapped to the actual exam domains, is the practical version of the argument this post is making in miniature.

I put together the complete case for why hands-on training beats theory-first content for cloud specifically, with the research and the practical format that makes it work, over here: Hands-On Labs vs Theory: Practical Cloud Training Approach.

Has your own retention matched this pattern, or have you had a topic that stuck fine from video alone? Drop it in the comments. 👇

I Simulated 3 Training Paths to See Which Breaks Even Fastest

Sherdil IT Academy — Fri, 09 Oct 2026 07:05:31 +0000

"Just do it yourself for free" and "pay for a structured program" get argued as if one is obviously right. Neither is, on its own, because they trade cost for time differently, and time has a cost too. Here's a small simulation that makes the tradeoff explicit instead of arguing about it in the abstract.

The three paths, modeled

def months_to_breakeven(upfront_cost, months_to_hireable, monthly_salary_lift, opportunity_cost_per_month=0):
    """
    upfront_cost:            cash spent on the path itself
    months_to_hireable:      realistic months until the new skill is job-ready
    monthly_salary_lift:     salary increase once hired/promoted into the role
    opportunity_cost_per_month: income foregone each month while training (0 if studying alongside a job)
    """
    total_cost = upfront_cost + (opportunity_cost_per_month * months_to_hireable)
    if monthly_salary_lift <= 0:
        return float("inf")
    return months_to_hireable + (total_cost / monthly_salary_lift)

paths = {
    "Self-study (free resources, alongside a job)": dict(
        upfront_cost=15_000,          # practice exams, occasional paid resource
        months_to_hireable=10,        # slower without structure or accountability
        monthly_salary_lift=35_000,
        opportunity_cost_per_month=0, # studying evenings/weekends, no income lost
    ),
    "Paid bootcamp (part-time, alongside a job)": dict(
        upfront_cost=120_000,
        months_to_hireable=4,
        monthly_salary_lift=35_000,
        opportunity_cost_per_month=0,
    ),
    "Employer-sponsored (full-time, company pays and schedules it)": dict(
        upfront_cost=0,                # employer pays
        months_to_hireable=3,
        monthly_salary_lift=20_000,    # smaller lift: often a role change, not external offer
        opportunity_cost_per_month=0,  # still salaried throughout
    ),
}

for name, params in paths.items():
    print(f"{name}: {months_to_breakeven(**params):.1f} months total to break even")

Self-study (free resources, alongside a job): 10.4 months total to break even
Paid bootcamp (part-time, alongside a job): 7.4 months total to break even
Employer-sponsored (full-time, company pays and schedules it): 3.0 months total to break even

What the numbers are actually saying

Employer-sponsored training wins by a wide margin whenever it is genuinely available, which is unsurprising, zero upfront cost and no income gap are hard to beat. The more interesting comparison is self-study against a paid bootcamp, because that is the decision most people are actually facing. In this model, the bootcamp breaks even three months sooner than self-study, purely because structure compresses the "months to hireable" number more than its PKR 120,000 fee costs in opportunity. That gap closes or reverses fast if you change one assumption: someone with strong self-discipline who can realistically hit a 5 or 6-month self-study timeline instead of 10 erases the bootcamp's advantage almost entirely.

The assumption that decides the whole comparison

months_to_hireable is doing more work in this model than the fee is. Change it and the ranking flips:

# Same self-study path, but with real discipline and a fixed weekly schedule
disciplined_self_study = dict(upfront_cost=15_000, months_to_hireable=5,
                               monthly_salary_lift=35_000, opportunity_cost_per_month=0)
print(months_to_breakeven(**disciplined_self_study))  # 5.4 months -> now beats the bootcamp

This is the honest finding: the fee is not what decides whether paid training is worth it. Your own realistic timeline is. Paying for structure is really paying to compress that one number, and whether that purchase is worth it depends entirely on how honestly you can estimate your own self-study pace, not on comparing fees.

Run it with your own numbers

Swap in your actual cost, your actual estimated timeline for each path, and your actual expected salary lift. The model is deliberately simple so you can sanity-check every input instead of trusting a black box. If you want the certification-fee side of this filled in with real 2026 pricing, here's the complete breakdown of what cloud certifications actually cost in Pakistan, hidden costs included, which plugs directly into the upfront_cost field above.

I put together the complete ROI analysis for Pakistani professionals, the full methodology, and realistic timelines by specialization, over here: Cloud Training ROI Investment Analysis for Pakistani Professionals.

Run your own months_to_hireable estimate honestly. Did self-study or paid training come out ahead for you? Drop it in the comments. 👇

I Built a Calculator So I'd Stop Guessing at Certification ROI

Sherdil IT Academy — Tue, 06 Oct 2026 09:42:03 +0000

Every certification ROI conversation I have ends up the same way: someone eyeballs a fee against a possible salary bump and calls it "probably worth it." That is not a calculation, it is a vibe. So I wrote a small calculator that forces the actual inputs onto the table, retake risk and study time included, instead of just the fee.

The model

def cert_total_cost(exam_fee, retake_probability, study_hours, hourly_value, extras=0):
    """
    exam_fee:           base exam fee, local currency
    retake_probability: 0-1, your honest odds of needing a second attempt
    study_hours:        realistic hours to prepare
    hourly_value:       what an hour of your time is worth to you (income, or opportunity cost)
    extras:              practice exams, lab credits, etc.
    """
    expected_exam_cost = exam_fee * (1 + retake_probability)
    time_cost = study_hours * hourly_value
    return round(expected_exam_cost + time_cost + extras)


def payback_months(total_cost, monthly_salary_lift):
    if monthly_salary_lift <= 0:
        return float("inf")
    return round(total_cost / monthly_salary_lift, 1)

The function most people skip in their head is retake_probability. A 30% chance of a second attempt is not a footnote, it is 30% more exam fee baked into the real cost before you have sat it once.

Running real numbers

# AZ-104, moderate confidence, studying around a full-time job
az104_cost = cert_total_cost(
    exam_fee=46_000,       # PKR
    retake_probability=0.25,
    study_hours=80,
    hourly_value=400,      # PKR/hour opportunity cost
    extras=8_000,          # practice exams
)
print(az104_cost)          # 97,500
print(payback_months(az104_cost, monthly_salary_lift=35_000))  # 2.8 months

# A Professional-level GCP exam, same assumptions scaled up
gcp_pro_cost = cert_total_cost(
    exam_fee=56_000,
    retake_probability=0.35,
    study_hours=140,
    hourly_value=400,
    extras=12_000,
)
print(gcp_pro_cost)        # 143,600
print(payback_months(gcp_pro_cost, monthly_salary_lift=45_000))  # 3.2 months

The Professional-level exam costs almost 50% more once study time and retake risk are priced in, but the payback window only stretches by about half a month, because the salary lift scales with it. That is the entire point of running the number instead of comparing fees side by side: the sticker price alone would have made the gap between these two look much larger than it actually is.

Why `hourly_value` is the variable worth arguing about

This is the input people get wrong in both directions. Set it too low and every certification looks free. Set it to your full salary rate and even a cheap exam looks expensive, because you are implicitly assuming every study hour displaced an hour of paid work, which is rarely true for evening or weekend study. A reasonable middle ground for most people is somewhere between zero and your actual hourly rate, scaled by how much that time would otherwise have gone to something valuable.

What the calculator will not tell you

It gives you a number, not a decision. It cannot tell you whether a certification's market demand is durable, or whether the skill underneath it is one you will actually enjoy using for the next few years. For a specific example of working through the certification-choice question with those non-financial factors included, here's how to decide which GCP certification to sit first, based on your actual role rather than the fee alone.

I put the full cost breakdown in one place, exam by exam with 2026 pricing, hidden costs most people forget to budget, and the complete payback math by certification, over here: Cloud Certification Costs Pakistan 2026: Is the Investment Worth It?".

Run your own numbers through this. What's your honest retake_probability, and does the payback window surprise you? Drop it in the comments. 👇

I Deployed the Same App to AWS, Azure, and GCP. Here's What Transfers.

Sherdil IT Academy — Mon, 28 Sep 2026 10:24:44 +0000

"Multi-cloud" gets thrown around as if clouds were interchangeable once you know one. They are not, but they are also not as different as vendor marketing wants you to believe. The only way to find out where the real line sits is to deploy the same thing three times and pay attention to what actually transferred. So I took one containerized app and pushed it to AWS, Azure, and GCP in the same afternoon. Here is exactly what carried over and what did not.

The same container, three CLIs

# AWS: push to ECR, deploy to App Runner
aws ecr create-repository --repository-name demo-app
docker push <account>.dkr.ecr.us-east-1.amazonaws.com/demo-app:v1
aws apprunner create-service --service-name demo-app --source-configuration file://source.json

# Azure: push to ACR, deploy to Container Apps
az acr create --name demoacr --resource-group demo-rg --sku Basic
docker push demoacr.azurecr.io/demo-app:v1
az containerapp create --name demo-app --resource-group demo-rg --image demoacr.azurecr.io/demo-app:v1

# GCP: push to Artifact Registry, deploy to Cloud Run
gcloud artifacts repositories create demo-repo --repository-format=docker --location=us-central1
docker push us-central1-docker.pkg.dev/PROJECT/demo-repo/demo-app:v1
gcloud run deploy demo-app --image us-central1-docker.pkg.dev/PROJECT/demo-app:v1

Three completely different command syntaxes. If you only measure "how many new commands did I type," multi-cloud looks brutal. That is the wrong measurement.

What actually transferred

The concepts did, almost entirely. Every one of these deployments needed the same mental checklist:

A container registry, authenticated before push
A managed compute layer that pulls from that registry and runs the container
Environment variables and secrets injected at deploy time, not baked into the image
A public endpoint with HTTPS handled for me
Logs and basic metrics available without extra setup

Once I had that checklist in my head from the AWS pass, the Azure and GCP passes were mostly "find the equivalent command," not "relearn the idea." The second cloud took under half the time of the first. The third took less than that.

What did not transfer, and cost real time

IAM was the honest exception. AWS IAM policies, Azure RBAC role assignments, and GCP IAM bindings are conceptually similar, permissions attached to identities, but the syntax, the scoping model, and the default-deny versus default-allow behavior differ enough that I made a real mistake on each cloud the first time through: an over-permissive service account here, a missing role binding there. Networking defaults were the second exception; what counts as "publicly reachable by default" is not the same answer on all three.

# The three IAM mental models, compressed
# AWS: attach a policy document to a role, mostly allow-by-exception
# Azure: assign a built-in or custom role to a principal at a scope (sub/RG/resource)
# GCP: bind a role to a member on a resource, IAM is closer to the surface everywhere

What this means for how you should actually train

If a course teaches "AWS from scratch," "Azure from scratch," and "GCP from scratch" as three unrelated modules, it is teaching the syntax three times and the concepts zero times, which is the slow way to get multi-cloud competent. The efficient path is the opposite: learn the concepts once, deep, on whichever cloud your job actually uses, then treat every additional cloud as a syntax-and-IAM problem, not a fresh start. That is a very different training design than most bootcamps run, and it is worth knowing which kind of program you are signing up for before you pay.

This distinction matters even more once you are past learning for yourself and into upskilling a whole team, where the cost of teaching three clouds as three separate courses multiplies fast. If that is the situation you are in, how corporate cloud training for development teams in Pakistan actually approaches this differently is worth reading before you scope a training budget.

I wrote up the complete case for why multi-cloud training is where the market is heading, and what a well-designed multi-cloud curriculum actually looks like, over here: Why Multi-Cloud Training Is the Future: Pakistan's Cloud Academy Landscape.

If you've deployed to more than one cloud, was IAM the thing that tripped you up too, or was it something else? Drop it in the comments. 👇

Stop Comparing Cloud Institutes by Vibes: A 20-Line Scoring Script

Sherdil IT Academy — Fri, 25 Sep 2026 11:29:32 +0000

If you are choosing a cloud training institute in Pakistan, you have probably done the same thing most people do: visited a few websites, sat through a couple of sales calls, and picked the one that felt most convincing. The problem is that "felt convincing" is exactly what a sales call is engineered to produce. So here is a way to take your own judgment out of the sales room and put it on paper: a weighted scorecard, in about twenty lines of Python.

The idea

Pick the factors that actually predict a good outcome, decide how much each one matters to you, rate every institute on each factor from 0 to 5, and let arithmetic do the comparison. The weights are the important part, because they force you to admit what you actually care about before you see any brochure.

WEIGHTS = {
    "hands_on_labs":     30,  # share of class time spent in real environments
    "instructor_current": 20,  # still working in the field, not just teaching
    "cert_alignment":    20,  # syllabus maps to the exam's published objectives
    "mentor_ratio":      15,  # realistic student-to-mentor support
    "placement_support": 10,  # interview prep, referrals, portfolio review
    "cost_transparency":  5,  # exam fees, retakes, extras stated up front
}

def score(ratings: dict) -> float:
    """ratings: each factor rated 0-5. Returns a score out of 100."""
    return sum(WEIGHTS[k] * ratings[k] / 5 for k in WEIGHTS)

institute_a = {"hands_on_labs": 4, "instructor_current": 3, "cert_alignment": 4,
               "mentor_ratio": 2, "placement_support": 3, "cost_transparency": 5}
institute_b = {"hands_on_labs": 2, "instructor_current": 5, "cert_alignment": 3,
               "mentor_ratio": 4, "placement_support": 4, "cost_transparency": 3}

print(score(institute_a))  # 69.0
print(score(institute_b))  # 67.0

The two institutes above are hypothetical, chosen to show a close call. On these weights, A edges out B by two points, mostly because it is lab-heavy.

Why the weights matter more than the ratings

Now change one thing: suppose you know you struggle without hands-on guidance, so you shift weight from labs to mentoring.

WEIGHTS.update({"hands_on_labs": 20, "mentor_ratio": 25})

print(score(institute_a))  # 65.0
print(score(institute_b))  # 71.0

The ranking flipped, and nothing about either institute changed. Only your priorities did. That is the whole point of the exercise: the "best" institute is not a fact about the institute, it is a fact about the match between the institute and you. Any published ranking, including ours, is answering someone else's weights.

How to fill in the ratings honestly

A score is only as good as the evidence behind it, so rate from things you can verify, not from things you were told.

Hands-on labs: ask for the syllabus and count lab sessions against lecture sessions.
Instructor current: check their recent work history, not their five-year-old bio.
Cert alignment: the syllabus should reference the exam's real domains by name.
Mentor ratio: ask for the actual batch size and how many people answer questions, not the marketing number.
Placement support: ask for a specific recent example, a role and a timeline, not a percentage.
Cost transparency: get exam fees and retake costs in writing before you pay.

If an institute will not answer one of these, rate that factor a 0 or 1. Evasion is data.

One limit of any scorecard

A spreadsheet cannot see delivery quality. Two institutes with identical syllabi can teach very differently, so treat the score as a way to shortlist two or three candidates, then sit in on a trial class before you decide. If you are shortlisting specifically in Karachi, what to look for in a top IT training academy there, including the red flags worth walking away from pairs well with this script, since it covers the local details a generic rubric will miss.

*I ran this kind of comparison across the cloud training market in Pakistan and wrote up the full findings, institute by institute, over here: Best Cloud Computing Training Institutes in Pakistan 2025-2026: Comparison.

What weight would you put on hands-on labs versus mentoring? Drop your numbers in the comments and see whose ranking changes. 👇

I Deployed a Model to Production. The ML Part Was the Easy 20%.

Sherdil IT Academy — Thu, 24 Sep 2026 10:53:27 +0000

Training a model that scores well on a validation set takes an afternoon with the right tutorial. Getting that same model to serve real traffic, reliably, without quietly burning through a cloud budget, took me longer than the training did. That gap is not a machine learning problem. It is a cloud engineering checklist, and here is what is actually on it.

Step 1: containerize the model, not the notebook

A notebook is not a deployable artifact. The first real step is packaging inference code into a container with a pinned, minimal dependency set.

# A serving image should be small and boring, not a full training environment
docker build -t model-serve:v1 .
docker run -p 8080:8080 model-serve:v1
curl -X POST localhost:8080/predict -d '{"input": [...]}'

If your image is several gigabytes because it includes the full training toolchain, split it. Training and serving have almost nothing in common as workloads.

Step 2: push it somewhere a scheduler can find it

# Tag and push to a registry your cluster or managed service can pull from
docker tag model-serve:v1 gcr.io/your-project/model-serve:v1
docker push gcr.io/your-project/model-serve:v1

Step 3: deploy with resource limits set on purpose, not left default

This is the step that separates a working demo from a production service. GPU and memory limits are not optional extras.

# GKE example: a deployment with explicit resource requests/limits
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serve
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: model-serve
        image: gcr.io/your-project/model-serve:v1
        resources:
          requests: {cpu: "1", memory: "2Gi"}
          limits: {cpu: "2", memory: "4Gi", nvidia.com/gpu: "1"}
EOF

Leave limits unset and one bad request, or one memory leak, can take down every other workload sharing the node. This is the single most common mistake in a first production deployment.

Step 4: put autoscaling on both ends, not just replicas

kubectl autoscale deployment model-serve --min=2 --max=10 --cpu-percent=70

Scaling replicas up under load is the easy half. The harder half is scaling back down aggressively when traffic drops, since idle GPU time is the line item that quietly wrecks a budget. Check your scale-down settings, not just the scale-up ones.

Step 5: monitor latency and cost as one dashboard, not two

# Vertex AI example: check endpoint metrics from the CLI
gcloud ai endpoints describe ENDPOINT_ID --region=us-central1

Watch p99 latency and hourly spend side by side. A model that is fast but expensive and a model that is cheap but slow both fail the same way in production: someone eventually turns them off.

Step 6: have a rollback that takes one command

kubectl rollout undo deployment/model-serve

If rolling back requires a manual process, it will not happen fast enough when it matters. Test the rollback before you need it, not during an incident.

What this list actually is

None of these six steps required a machine learning skill. They required cluster and infrastructure fundamentals applied to a workload that happens to serve a model instead of a web app. That is exactly the gap that is opening up in the market right now: plenty of people can train a model, and a shorter supply of people can be trusted to run one.

If this checklist felt more familiar than the modeling itself, that is worth paying attention to. The roles built around exactly this skill set are growing faster than the general cloud job market right now, and knowing where they actually are matters more than knowing they exist. I mapped out where the current AI-adjacent cloud demand sits in Pakistan, sector by sector, over here: what the cloud computing job market in Pakistan actually looks like right now.

I put the complete picture together, the specific skills that map to each stage of an ML pipeline, realistic salary data for AI-adjacent cloud roles, and where demand is concentrated, over here: AI and Cloud Computing in Pakistan: Why Machine Learning Needs Cloud Engineers.

Which of these six steps have you actually had to debug at 2am? Drop it in the comments. 👇

6 Weeks of Hands-On Azure CLI Labs to Pass the AZ-104

Sherdil IT Academy — Tue, 15 Sep 2026 10:08:31 +0000

The AZ-104 is a performance-based exam. You are clicking through the actual Azure portal and typing real commands under a timer, not answering multiple choice about what a resource group is. Which makes it strange how much AZ-104 prep still consists of watching four-hour video courses and taking notes. Notes do not build the muscle memory the exam is actually testing.

So here is the plan I would run instead: 6 weeks, entirely hands-on, built around the free-tier Azure sandbox and the Azure CLI, mapped directly to the exam's own skill domains.

Before week 1: set up the sandbox

Use a free Azure account or the Microsoft Learn sandbox, not a shared work subscription. You need permission to break things.

az login
az account set --subscription "<your-sub-id>"
az group create --name az104-lab --location eastus

Every week below assumes you are working inside this one resource group, and tearing pieces of it down as you go, which is itself part of the exam's skill set.

Weeks 1-2: Identity and governance

This domain is roughly 20% of the exam and the one people skip in video courses because it feels administrative. It is not administrative on exam day.

# Create a user and assign a role at resource-group scope
az ad user create --display-name "Lab User" --user-principal-name labuser@yourtenant.onmicrosoft.com --password "TempPass123!"
az role assignment create --assignee labuser@yourtenant.onmicrosoft.com --role "Contributor" --resource-group az104-lab

# Apply a resource lock so you cannot accidentally delete the group mid-lab
az lock create --name dont-delete --resource-group az104-lab --lock-type CanNotDelete

By the end of week 2, you should be able to explain the difference between a role assignment at subscription, resource-group, and resource scope without looking it up.

Weeks 3-4: Storage, compute, and networking

The largest single chunk of the exam, and the one that rewards raw repetition.

# Storage: create an account and a container, then lock down public access
az storage account create --name az104labstorage --resource-group az104-lab --sku Standard_LRS
az storage container create --name lab-container --account-name az104labstorage --public-access off

# Compute: spin up a VM and immediately resize it
az vm create --resource-group az104-lab --name lab-vm --image Ubuntu2204 --generate-ssh-keys
az vm resize --resource-group az104-lab --name lab-vm --size Standard_B2s

# Networking: create a VNet and a subnet, then check effective routes
az network vnet create --resource-group az104-lab --name lab-vnet --subnet-name lab-subnet
az network nic show-effective-route-table --resource-group az104-lab --name lab-vmVMNic

Do each of these commands at least three times across the two weeks, changing one parameter each time. The exam rewards fluency, not familiarity.

Weeks 5-6: Monitoring and troubleshooting

The domain most people under-prepare for, because it is the hardest to fake with flashcards.

# Enable diagnostic logging and query it back
az monitor diagnostic-settings create --name lab-diag --resource /subscriptions/<sub-id>/resourceGroups/az104-lab/providers/Microsoft.Compute/virtualMachines/lab-vm --logs '[{"category": "Administrative","enabled": true}]' --storage-account az104labstorage

# Simulate a failure and practice reading it
az vm stop --resource-group az104-lab --name lab-vm
az vm get-instance-view --resource-group az104-lab --name lab-vm --query instanceView.statuses

Deliberately break something in your own sandbox during week 6, a wrong NSG rule, a stopped VM a dependent service expects to be running, and practice diagnosing it from the CLI output alone. That is a closer simulation of exam pressure than any video course gets you.

Tear it all down

az group delete --name az104-lab --yes --no-wait

Do this at the end of every week, not just at the end of the plan. Rebuilding the resource group from scratch each time is itself repetition, and it keeps you from accumulating a messy sandbox that no longer reflects a clean exam-day state.

What this does not replace

A lab plan gets you fluent with the tooling. It does not replace working through the official exam skills outline line by line, or sitting a few timed practice exams in the final week to get used to the two-hour pace. Treat this as the hands-on 80%, not the whole 100%.

I put the complete picture in one place: the current 2026 exam fee in PKR, what a realistic study timeline actually looks like around a full-time job, and the free resources worth using before you pay for anything, over here: Azure AZ-104 Exam Cost & Preparation Guide for Pakistani Professionals.

Once you pass, what does the AZ-104 actually add to your paycheck as an Azure Administrator in Pakistan? Worth knowing before you commit six weeks to this.

Which domain above is the one you'd need to lab the hardest? Drop it in the comments. 👇

The Kubernetes Exam Your Daily kubectl History Already Chose

Sherdil IT Academy — Mon, 31 Aug 2026 07:25:08 +0000

Every syllabus comparison of the CKA and the CKAD tells you the same thing: one is broader, one is narrower, both are two hours, both need 66%, both are 100% hands-on. None of that actually tells you which one to sit. What tells you is far simpler and sitting right there in your shell history: the commands you already run against a cluster every week.

Instead of another domain-by-domain breakdown, run this 5-command self-test. It takes less time than reading a syllabus PDF.

The self-test

Open your shell history (history | grep kubectl, or just think back to last week) and check off which of these five you actually typed, not which ones you know exist.

# 1. Node-level operations
kubectl drain node-3 --ignore-daemonsets
kubectl cordon node-3

# 2. Cluster state backup/restore
etcdctl snapshot save /backup/etcd-snap.db

# 3. Cluster-wide access control
kubectl create rolebinding dev-binding --role=dev-role --user=jane -n team-a

# 4. Rolling out an application change
kubectl set image deployment/api api=myorg/api:v2.3
kubectl rollout status deployment/api

# 5. Application-level debugging
kubectl describe pod api-7d9f8 | grep -A5 Events
kubectl logs api-7d9f8 --previous

Commands 1 through 3 are cluster-owner work: you are responsible for the machine underneath the workloads, not just the workloads. Commands 4 and 5 are the daily reality of shipping and debugging an application on infrastructure someone else keeps running.

Scoring it

If your real, honest history leans 1-2-3, that is a CKA profile. The exam's four domains, cluster architecture, workloads and scheduling, services and networking, and troubleshooting, are all written from the point of view of the person who owns the node, not just the pod running on it.

If your history leans 4-5, that is a CKAD profile. Its domains, application design, deployment configuration, observability, and application environment, assume the cluster is a given and test how fast and correctly you can ship and fix what runs on top of it.

Most engineers do not sit at either extreme. If you are close to even, the tiebreaker is not preference, it is the market: over 80% of Kubernetes job postings in Pakistan in 2026 name the CKA specifically, even for roles that lean closer to application deployment day-to-day. When the self-test is a genuine toss-up, that market data is the deciding vote, not a coin flip.

Why this beats a syllabus comparison

A syllabus tells you what is testable. It does not tell you what is natural. Two engineers can read the identical CKA domain list and one will find etcd restore drills intuitive because they have broken a cluster and fixed it before, while the other will find the same drills exhausting because their daily work never touches that layer. Preparation time roughly triples when you are studying a domain that is not already close to your muscle memory. The self-test above is really a proxy for that: it tells you which exam you can prepare for in 12 weeks without fighting your own instincts the whole way.

The certification is one line item, not the whole plan

Whichever exam the self-test points you to, it is worth remembering that a certification is a single, well-defined credential inside a much longer career arc, not a career plan by itself. If you are mapping out where a Kubernetes credential actually sits relative to the rest of the skill stack, from Linux fundamentals through to a lead or architect title, the complete DevOps Career Guide for Pakistan lays out the full seven-to-ten-year path and exactly where a CKA or CKAD pays off most along it.

I put the full comparison in one place: the 2026 PKR pricing for both exams, role-based recommendations, and the salary premium each certification carries in the Pakistani market, over here: Kubernetes Certification Pakistan: CKA vs CKAD.

Ran the self-test. Which side did your real history land on, and did the exam you sat match it? Drop it in the comments. 👇

A Free 16-Week Cloud and DevOps Syllabus for Karachi (2026)

Sherdil IT Academy — Mon, 17 Aug 2026 08:21:08 +0000

Every free resource you need to go from zero to a genuinely hireable cloud or DevOps skill set already exists, and most of it is free. The problem was never access. The problem is that nobody hands you an order, so people bounce between AWS Skill Builder, random YouTube tutorials, and a Udemy course they never finish, and eight months later they still could not tell you what job they are qualified for.

So here is a fixed syllabus. Sixteen weeks, entirely free resources, no ambiguity about what to do next. Follow it in order.

Weeks 1 to 3: Linux and the command line

Nothing else on this list works without this foundation.

freeCodeCamp's Linux fundamentals content (YouTube) for the core commands, file permissions, and process management
Practice daily in a free-tier virtual machine or WSL, not just by watching

By the end of week 3 you should be comfortable navigating a server with no GUI, editing files in vim or nano, and managing basic services with systemctl.

# Daily practice habit, not optional
ssh into your VM every day, even for ten minutes
systemctl status <any-service>
journalctl -u <any-service> --since today

Weeks 4 to 6: Git and one programming language

freeCodeCamp again, this time for Python or JavaScript fundamentals
Git and GitHub, practiced by committing something daily, not just reading about branches

By week 6 you should have a GitHub profile with actual commit history, not a blank green square.

Weeks 7 to 10: Pick one cloud, go deep

This is the point where people scatter across AWS, Azure, and GCP at once and slow themselves down. Pick one.

AWS Skill Builder (free tier) if you are targeting the widest local hiring base
Google Cloud Skills Boost if your target companies run GCP
Microsoft Learn if you already know you are heading into a bank or an Azure shop

Whichever you pick, do the hands-on labs, not just the reading modules. Deploy something real: a static site, a small API, a database-backed app. Screenshot it working and write a short note on what you built and why.

Weeks 11 to 13: Containers and Kubernetes

KodeKloud's free YouTube content for Docker and Kubernetes fundamentals
TechWorld with Nana for the conceptual explanations that make Kubernetes click
Build a local cluster (Minikube or Kind) and deploy your week 7 to 10 project into it

# Minimum viable proof you understand the basics
kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>

By the end of week 13, you should be able to explain what a Pod, a Deployment, and a Service each do, and why you would use one over another.

Weeks 14 to 16: CI/CD and one real end-to-end project

GitHub Actions documentation and examples (free, and the most commonly used CI/CD tool for portfolio projects)
Wire your containerized app from weeks 11 to 13 into a pipeline: commit triggers build, build triggers deploy

This is the single most important project on the whole syllabus. One complete pipeline, end to end, on your GitHub, proves more than every certificate of completion combined.

What this syllabus does not include, on purpose

It does not include every free resource that exists. DigiSkills, NAVTTC, and the other government programs are worth exploring, but they overlap heavily with what is already listed here, and running two curricula at once is how people stall. Pick this syllabus or a government program, not both at the same time.

It also does not end with a certification, deliberately. This sequence builds the skill. What you do with it next, whether that is applying for jobs directly or adding a formal certification like the CKA to make the skill legible to recruiters, is a separate decision. If you finish this syllabus and want the credential that makes 80% of local Kubernetes job postings take you seriously, the full CKA certification prep guide for Pakistani engineers picks up exactly where week 16 leaves off.

The honest timeline

Following this syllabus at a genuine 10 to 12 hours a week, sixteen weeks gets you to a real, demonstrable skill level, not a finished career. Expect another few months of job searching and interview practice after that. It is slower than a paid bootcamp, and it costs nothing but the hours you put in.

This 16-week path is one route through it. I put together the complete list of every genuinely useful free program available in Karachi in 2026, government and vendor programs included, along with honest notes on where each one is weak, over here: "free IT courses in Karachi".

Where are you on this syllabus right now, and which phase has taken longer than you expected? Drop it in the comments. 👇

7 Questions to Ask Before Paying for an IT Course in Karachi

Sherdil IT Academy — Mon, 03 Aug 2026 07:18:20 +0000

Karachi does not have a shortage of IT courses. It has a shortage of good ones, buried inside a much larger pile of institutes selling outdated slide decks at bootcamp prices. With fees running anywhere from PKR 40,000 to 180,000 depending on the specialization, picking wrong is not a small mistake. It is months of time and real money.

I get asked "which institute should I join" often enough that I built a fixed checklist. It is not about brand names. It is seven questions that expose the difference between a course built for outcomes and a course built to fill seats.

1. Who is teaching, and are they still doing the work?

Ask for the instructor's current job title, not their job title from five years ago. Cloud, DevOps, and security move fast, and an instructor who has not touched a production system recently is teaching from memory, not from practice. A quick LinkedIn check settles this in two minutes.

2. Is the curriculum hands-on or slide-based?

Ask what percentage of class time is lab work versus lecture. For technical fields like AWS, Kubernetes, or cloud security, anything below 60 percent hands-on is a red flag. You are not paying to watch slides; you can get slides for free. You are paying for guided practice on real environments with someone there to unblock you when something breaks.

3. What do graduates actually build?

Ask to see finished student projects, not marketing testimonials. A real program produces a portfolio: a deployed app, a hardened cluster, a CI/CD pipeline someone can point to in an interview. If the institute cannot show you specific student work, they likely are not producing it.

4. Does the fee include the certification exam?

Certification vouchers (AWS, CKA, AZ-500) cost real money on top of the course itself. Some providers bundle the exam fee; many do not, and only mention that after you have paid. Get this in writing before you enroll, because it can add tens of thousands of rupees to what looked like a fixed price.

5. Is there any placement or interview support?

A course that ends the day the class ends is teaching, not career support. Ask specifically what happens after: mock interviews, resume review, referrals, or a portfolio review session. Programs that treat placement as part of the product, not an afterthought, tend to be run by people who actually track outcomes.

6. What is the batch size, and who answers questions?

A 60-person batch with one instructor means you are mostly on your own. Ask the actual student-to-mentor ratio, not the marketing number. This single detail predicts more about your experience than almost anything else on this list.

7. Can they show you a hiring outcome, specifically?

Not "our students get placed." Ask for a specific example: a name, a company, a rough timeline from course completion to offer. Vague claims are cheap to make. Specific, checkable ones are not.

Reading the answers together

No single answer disqualifies a provider on its own. But if you ask all seven and get vague or dodged answers on more than two or three, that is your answer. The Karachi IT training market has genuinely strong providers in it. It also has a lot of noise. This checklist is how you tell them apart before you pay, not after.

Where this actually leads

The reason to be this careful is that the destination is real. Cloud, DevOps, and especially cloud security remain some of the most underserved technical niches in Pakistan's job market right now, and the pay gap between a well-trained engineer and a self-taught one closes fast once you can prove hands-on skill. If security is the direction you are weighing, it is worth understanding [what the cloud security career path actually looks like in Pakistan][INTERNAL] before you pick a course, since the right training decision depends on which of those roles you are actually aiming for.

*I put the full picture together in one place: fee ranges by specialization, the specific in-demand courses for 2026, and a deeper breakdown of free versus paid options, over here: IT courses in Karachi for 2026.

Which of these seven questions have you never thought to ask before enrolling somewhere? Drop it in the comments. 👇