DevOps

Modul 1 · Lab SOC mini: aturan deteksi, triase berbantuan AI, dan laporan insiden

Bangun lab SOC di laptop Anda memakai log serangan yang direkam ulang (dataset disediakan). Tulis aturan deteksi, ukur kinerjanya, lakukan triase dengan bantuan LLM, dan tulis laporan insiden lengkap. Setiap kesimpulan AI yang Anda pakai harus diverifikasi terhadap log asli. Tahapan pengerjaan • Kerangka: Arsitektur lab, sumber log, dan daftar teknik serangan yang ingin dideteksi beserta alasannya. • Draf: SIEM berjalan, log mengalir, dan minimal 5 aturan deteksi aktif beserta hasil uji awal. • Revisi: Minimal 8 aturan, positif palsu dikurangi berdasarkan data, alur triase berbantuan LLM berjalan, dan umpan balik reviewer ditindaklanjuti. • Final: Laporan insiden lengkap untuk skenario yang diberikan, catatan verifikasi atas kesimpulan AI, dan pemetaan ATT&CK.

Yang diserahkan: Tautan repositori berisi konfigurasi lab dan aturan deteksi, tabel kinerja deteksi (positif benar dan positif palsu), dan laporan insiden maksimal 5 halaman.

• Kualitas deteksibobot 30% · skor 0–4

  Aturan menangkap teknik sasaran dengan positif palsu yang terkendali dan terukur.

• Ketepatan triasebobot 25% · skor 0–4

  Prioritas dan eskalasi tepat; kesimpulan AI diverifikasi terhadap bukti, bukan diterima begitu saja.

• Investigasi dan kronologibobot 20% · skor 0–4

  Kronologi insiden akurat dan didukung bukti log.

• Laporan insidenbobot 15% · skor 0–4

  Laporan jelas untuk pembaca teknis dan manajemen, dengan rekomendasi yang bisa ditindaklanjuti.

• Pemetaan ATT&CKbobot 10% · skor 0–4

  Deteksi dipetakan dengan benar ke taktik dan teknik.

Modul 2 · Pipeline CI/CD dengan gerbang keamanan berlapis dan deploy GitOps yang teruji memblokir

Bangun pipeline untuk aplikasi contoh (disediakan) atau aplikasi Anda sendiri. Buktikan setiap gerbang bekerja dengan menyiapkan merge request yang sengaja berbahaya: rahasia yang ter-commit, dependensi rentan, image dengan kerentanan kritis, dan IaC yang membuka akses publik. Tahapan pengerjaan • Kerangka: Desain pipeline, daftar gerbang beserta kebijakan blokir atau peringatan, dan alasannya. • Draf: Pipeline berjalan dengan pemindaian kode, rahasia, dan dependensi. • Revisi: Pemindaian kontainer dan IaC, deploy GitOps, dan umpan balik reviewer ditindaklanjuti. • Final: Empat merge request berbahaya terblokir dengan bukti, SBOM dan tanda tangan artefak, serta kebijakan pengecualian.

Yang diserahkan: Tautan repositori dengan konfigurasi pipeline, tautan ke empat merge request uji beserta hasil pipeline-nya, dan dokumen kebijakan keamanan pipeline maksimal 3 halaman.

• Gerbang yang terbukti bekerjabobot 35% · skor 0–4

  Keempat perubahan berbahaya benar-benar terblokir dengan pesan yang jelas bagi pengembang.

• Desain kebijakanbobot 25% · skor 0–4

  Keseimbangan antara memblokir dan memperingatkan dibenarkan; pengecualian punya proses dan tenggat.

• Rantai pasokbobot 20% · skor 0–4

  SBOM dihasilkan dan artefak ditandatangani serta diverifikasi saat deploy.

• Deploy GitOpsbobot 20% · skor 0–4

  Deploy deklaratif, bisa diaudit, dan bisa dikembalikan ke versi sebelumnya.

Modul 3 · Pengamanan platform AI di cloud dengan model ancaman, kontrol berlapis, dan uji serangan

Amankan aplikasi AI contoh yang sengaja rentan, di lingkungan cloud milik Anda sendiri. Tulis model ancamannya, terapkan kontrol, lalu serang sistem Anda sendiri dengan minimal 10 skenario (termasuk prompt injection tidak langsung lewat dokumen yang diunggah) dan laporkan mana yang tertahan dan mana yang tidak. Semua pengujian hanya boleh dilakukan pada lingkungan milik Anda sendiri. Tahapan pengerjaan • Kerangka: Model ancaman (aset, pelaku, jalur serangan, prioritas) dan rancangan kontrol. • Draf: IAM, isolasi jaringan, dan pengelolaan rahasia diterapkan sebagai kode; pencatatan aktif. • Revisi: Kontrol khusus LLM diterapkan dan 10 skenario serangan dijalankan; umpan balik reviewer ditindaklanjuti. • Final: Laporan keamanan bergaya enterprise: ringkasan eksekutif, temuan, risiko yang tersisa beserta alasan menerimanya.

Yang diserahkan: Tautan repositori berisi kode infrastruktur dan aplikasi yang sudah diamankan, dokumen model ancaman, log uji serangan, dan laporan keamanan maksimal 6 halaman.

• Kualitas model ancamanbobot 25% · skor 0–4

  Ancaman diprioritaskan berdasarkan dampak dan kemungkinan, termasuk ancaman khas LLM; tidak sekadar daftar umum.

• Ketepatan kontrol cloudbobot 25% · skor 0–4

  IAM benar-benar minimum, jaringan terisolasi, dan rahasia terkelola, semuanya sebagai kode.

• Pertahanan aplikasi LLMbobot 25% · skor 0–4

  Prompt injection langsung dan tidak langsung serta kebocoran data ditangani berlapis, bukan dengan satu filter.

• Pengujian dan kejujuran temuanbobot 15% · skor 0–4

  Skenario serangan realistis; kegagalan kontrol dilaporkan apa adanya.

• Komunikasi risikobobot 10% · skor 0–4

  Laporan bisa dipakai pengambil keputusan; risiko yang tersisa beserta alasannya jelas.

Modul 3 · Rangkaian tes otomatis untuk aplikasi web dengan fitur LLM, berjalan di CI

Uji aplikasi contoh (disediakan; aplikasinya sengaja mengandung beberapa bug). Bangun rangkaian tes dan temukan sebanyak mungkin bug dengan bukti. Bila Anda memakai AI untuk menulis tes, catat tes mana yang Anda buang dan alasannya. Tahapan pengerjaan • Kerangka: Strategi tes, prioritas risiko, dan rencana cakupan. • Draf: Tes ujung ke ujung dan tes API untuk alur utama berjalan di CI. • Revisi: Set evaluasi untuk fitur LLM dan tes keamanan dasar; tes yang gagal acak diperbaiki; umpan balik reviewer ditindaklanjuti. • Final: Laporan bug beserta bukti, laporan kualitas, dan catatan penggunaan AI dalam menulis tes.

Yang diserahkan: Tautan repositori berisi tes dan konfigurasi CI, laporan bug (langkah reproduksi dan bukti), serta laporan kualitas maksimal 3 halaman.

• Strategi dan cakupan berbasis risikobobot 25% · skor 0–4

  Area berisiko tinggi teruji di level yang tepat; cakupan dibenarkan.

• Bug yang ditemukanbobot 25% · skor 0–4

  Bug yang disisipkan ditemukan dengan langkah reproduksi yang jelas.

• Pengujian fitur LLMbobot 25% · skor 0–4

  Set evaluasi menangani keluaran tidak deterministik dengan kriteria lulus yang masuk akal.

• Stabilitas dan kualitas tesbobot 15% · skor 0–4

  Tes stabil, mudah dibaca, dan tes buatan AI yang tidak bermakna sudah disaring.

• Pelaporanbobot 10% · skor 0–4

  Laporan kualitas bisa ditindaklanjuti oleh tim pengembang.

Modul 1 · Infrastruktur sebagai kode dan deployment Kubernetes untuk aplikasi AI tiga komponen

Deploy aplikasi AI tiga komponen (API, worker, basis data; aplikasi contoh disediakan) ke cloud pilihan Anda memakai Terraform dan Kubernetes. Reviewer akan membaca kode Anda untuk menilai apakah infrastruktur bisa dibangun ulang dari nol. Tetapkan anggaran bulanan dan buktikan infrastruktur Anda berada di bawahnya. Tahapan pengerjaan • Kerangka: Diagram arsitektur, pilihan layanan cloud beserta alasannya, dan estimasi biaya bulanan. • Draf: Terraform membuat klaster dan jaringan; aplikasi berjalan di Kubernetes. • Revisi: Rahasia dikelola dengan benar, autoscaling teruji dengan uji beban sederhana, dan umpan balik reviewer ditindaklanjuti. • Final: Bukti pemulihan dari kehilangan basis data, perbandingan biaya aktual dengan estimasi, dan prosedur pembongkaran infrastruktur.

Yang diserahkan: Tautan repositori berisi Terraform dan manifest Kubernetes, README untuk membangun ulang dari nol, hasil uji beban, dan laporan biaya.

• Reprodusibilitas infrastrukturbobot 30% · skor 0–4

  Infrastruktur bisa dibangun ulang dan dibongkar hanya dari kode; tidak ada langkah manual tersembunyi.

• Ketepatan deployment Kubernetesbobot 25% · skor 0–4

  Sumber daya, probe kesehatan, dan autoscaling dikonfigurasi dengan benar dan teruji.

• Keamanan dasarbobot 20% · skor 0–4

  Rahasia tidak ada di repositori, kontainer berjalan sebagai non-root, akses jaringan dibatasi.

• Kendali biayabobot 15% · skor 0–4

  Estimasi masuk akal dan biaya aktual dilaporkan jujur terhadap anggaran.

• Pemulihanbobot 10% · skor 0–4

  Pencadangan dan pemulihan basis data terbukti berjalan.

Modul 2 · Basis data PostgreSQL untuk katalog dengan pencarian teks, vektor, dan gabungan, beserta bukti kinerja

Rancang dan bangun basis data untuk katalog produk berukuran minimal 200.000 baris (generator dataset disediakan). Terapkan tiga jenis pencarian, ukur kualitas dan kecepatannya, lalu rekomendasikan mana yang dipakai untuk kasus apa. Tahapan pengerjaan • Kerangka: Model data, pola kueri utama, dan rencana indeks. • Draf: Skema dan data termuat, kueri transaksional teroptimasi dengan bukti rencana kueri. • Revisi: Pencarian teks penuh, vektor, dan gabungan berjalan dan diukur; umpan balik reviewer ditindaklanjuti. • Final: Row-Level Security, laporan kinerja, dan rekomendasi arsitektur.

Yang diserahkan: Tautan repositori berisi migrasi skema, skrip data, dan skrip pengukuran, serta laporan maksimal 5 halaman berisi tabel kinerja dan rekomendasi.

• Kualitas model databobot 25% · skor 0–4

  Skema ternormalisasi dengan tepat, tipe data benar, dan batasan integritas lengkap.

• Kinerja terbuktibobot 25% · skor 0–4

  Indeks dirancang dari pola kueri dan perbaikannya dibuktikan dengan rencana kueri dan pengukuran.

• Kualitas pencarianbobot 25% · skor 0–4

  Ketiga jenis pencarian berjalan; kualitas hasil diukur, bukan diasumsikan.

• Keamanan databobot 15% · skor 0–4

  Peran dan Row-Level Security membatasi akses dengan benar dan teruji.

• Rekomendasibobot 10% · skor 0–4

  Rekomendasi didukung angka dan jujur tentang batas PostgreSQL.

Modul 2 · Model ML untuk satu masalah berbasis data Indonesia dengan analisis kesalahan dan kartu model

Pilih satu masalah dan dataset (daftar dataset publik Indonesia disediakan). Bangun model, bandingkan dengan pembanding sederhana, analisis di mana model gagal, dan tulis kartu model. Akurasi tinggi tanpa analisis tidak lulus; akurasi biasa dengan analisis jujur bisa lulus. Tahapan pengerjaan • Kerangka: Rumusan masalah, metrik yang dipilih beserta alasannya, eksplorasi data, dan rencana pembagian data. • Draf: Pembanding sederhana dan minimal dua model, dievaluasi pada data uji yang sama. • Revisi: Perbaikan berdasarkan umpan balik reviewer, analisis kesalahan per segmen, dan pemeriksaan kebocoran data. • Final: Kartu model, notebook yang bisa dijalankan ulang, dan ringkasan satu halaman untuk pembaca non-teknis.

Yang diserahkan: Tautan notebook atau repositori yang bisa dijalankan ulang, kartu model (format disediakan), dan ringkasan eksekutif satu halaman.

• Rumusan masalah dan metrikbobot 20% · skor 0–4

  Metrik sesuai biaya kesalahan di dunia nyata, bukan sekadar akurasi.

• Metodologi yang benarbobot 30% · skor 0–4

  Pembagian data benar, tidak ada kebocoran, dan perbandingan model adil terhadap pembanding.

• Analisis kesalahanbobot 25% · skor 0–4

  Kegagalan model dianalisis per segmen dan potensi bias diidentifikasi.

• Komunikasi dan kartu modelbobot 15% · skor 0–4

  Kartu model jujur tentang batasan; ringkasan bisa dipahami pengambil keputusan.

• Reprodusibilitasbobot 10% · skor 0–4

  Hasil bisa diulang dari notebook atau repositori yang diserahkan.

Modul 1 · Analisis eksploratif satu dataset publik Indonesia dalam notebook Python

Pilih satu dataset publik Indonesia yang cukup besar (minimal ribuan baris). Rumuskan minimal tiga pertanyaan, bersihkan datanya, jawab setiap pertanyaan dengan angka dan grafik, lalu tulis temuan beserta batasannya. Tahapan pengerjaan • Kerangka: Dataset yang dipilih beserta sumber dan alasannya, tiga pertanyaan, dan rencana analisis. • Draf: Notebook pembersihan data dan analisis awal untuk ketiga pertanyaan. • Revisi: Perbaikan analisis sesuai umpan balik reviewer, ditambah visualisasi yang tepat. • Final: Notebook final yang berjalan dari awal sampai akhir, dan laporan temuan.

Yang diserahkan: Notebook yang bisa dijalankan ulang dari awal tanpa galat, berkas data atau tautan sumbernya, dan laporan temuan maksimal 2 halaman.

• Kebenaran kode dan pembersihan databobot 30% · skor 0–4

  Kode berjalan, dan langkah pembersihan tepat serta terdokumentasi.

• Ketepatan analisisbobot 25% · skor 0–4

  Angka dan perbandingan menjawab pertanyaan yang diajukan.

• Visualisasibobot 20% · skor 0–4

  Jenis grafik cocok dengan pertanyaan, berlabel jelas, dan tidak menyesatkan.

• Kejujuran temuanbobot 15% · skor 0–4

  Batasan data dan hal yang tidak bisa disimpulkan dinyatakan terbuka.

• Bisa diulangbobot 10% · skor 0–4

  Orang lain bisa menjalankan notebook dan mendapat hasil yang sama.

Modul 3 · Asisten pengetahuan RAG untuk satu kumpulan dokumen nyata, lengkap dengan set uji

Pilih satu kumpulan dokumen nyata yang boleh Anda pakai (minimal 30 dokumen, boleh dokumen publik seperti peraturan atau dokumentasi produk open source). Bangun asisten tanya-jawab di atasnya dan buktikan kualitasnya dengan angka. Tahapan pengerjaan • Kerangka: Dokumen yang dipilih dan alasannya, 20 pertanyaan uji beserta jawaban yang benar (termasuk minimal 5 pertanyaan yang jawabannya TIDAK ada di dokumen), dan rancangan arsitektur satu halaman. • Draf: Pipeline berjalan ujung ke ujung: ingest, embedding, pengambilan, jawaban dengan kutipan. Hasil pertama terhadap 20 pertanyaan uji. • Revisi: Perbaikan berdasarkan umpan balik reviewer dan hasil uji: strategi chunking, pengambilan gabungan, atau prompt. Tunjukkan angka sebelum dan sesudah. • Final: Repositori lengkap, video demo maksimal 5 menit, dan laporan evaluasi akhir termasuk satu skenario pembatasan akses dokumen.

Yang diserahkan: Tautan repositori Git (README berisi cara menjalankan), laporan evaluasi PDF maksimal 4 halaman berisi tabel hasil 20 pertanyaan uji, dan tautan video demo maksimal 5 menit.

• Ketepatan dan pembumian jawabanbobot 30% · skor 0–4

  Jawaban benar menurut dokumen, setiap klaim punya kutipan sumber yang bisa dicek, dan pertanyaan di luar dokumen dijawab 'tidak ditemukan' alih-alih dikarang.

• Kualitas pengambilanbobot 25% · skor 0–4

  Strategi chunking dan pengambilan dipilih dengan alasan, dan perbaikannya terukur antara draf dan final.

• Evaluasi yang jujurbobot 20% · skor 0–4

  Set uji mencakup kasus sulit dan kasus tanpa jawaban; angka dilaporkan apa adanya termasuk kegagalan.

• Keamanan akses dokumenbobot 15% · skor 0–4

  Pengguna tidak bisa mendapatkan isi dokumen yang bukan haknya lewat pertanyaan apa pun yang diuji.

• Kerapian rekayasabobot 10% · skor 0–4

  Kode bisa dijalankan orang lain dari README, kunci API tidak ada di repositori, biaya per pertanyaan diperkirakan.

Modul 5 · Sistem deteksi objek di perangkat untuk satu kasus nyata, dengan pengukuran kinerja

Pilih satu kasus deteksi objek yang nyata. Kumpulkan atau pilih dataset, latih ulang model, kecilkan ukurannya, lalu jalankan di perangkat. Laporkan perbandingan sebelum dan sesudah pengecilan: ukuran, kecepatan, dan akurasi. Tahapan pengerjaan • Kerangka: Kasus yang dipilih, perangkat sasaran, target kinerja, dan rencana dataset. • Draf: Model terlatih ulang dan berjalan di laptop dengan pengukuran awal. • Revisi: Model dikecilkan dan dijalankan di perangkat sasaran, alur aksi berjalan, dan umpan balik reviewer ditindaklanjuti. • Final: Video demo di perangkat dan laporan kinerja lengkap.

Yang diserahkan: Tautan repositori (kode, konfigurasi, dan cara menjalankan), laporan kinerja maksimal 4 halaman, dan video demo maksimal 5 menit.

• Kesesuaian dengan batasan perangkatbobot 25% · skor 0–4

  Pilihan model dan pengecilan sesuai dengan perangkat dan target kinerja yang ditetapkan.

• Akurasi pada kasus nyatabobot 25% · skor 0–4

  Akurasi diukur pada data uji yang mewakili kondisi nyata.

• Pengukuran kinerjabobot 25% · skor 0–4

  Ukuran, kecepatan, dan sumber daya diukur dengan benar sebelum dan sesudah pengecilan.

• Sistem utuhbobot 15% · skor 0–4

  Alur kamera sampai aksi berjalan dan menangani kegagalan seperti kamera terputus.

• Reprodusibilitasbobot 10% · skor 0–4

  Orang lain bisa menjalankan ulang dari repositori.

Modul 4 · Satu alur otomasi berbantuan AI untuk proses kerja nyata, lengkap dengan perhitungan hemat waktu

Pilih satu proses berulang yang Anda atau tim Anda kerjakan setiap minggu. Petakan prosesnya, otomatiskan dengan alat low-code dan AI, lalu jalankan selama minimal satu minggu dengan data nyata atau data contoh yang realistis. Hitung waktu yang dihemat. Data pelanggan yang asli harus disamarkan dalam bukti yang Anda serahkan. Tahapan pengerjaan • Kerangka: Peta proses saat ini (langkah, pelaku, waktu per langkah) dan bagian yang akan diotomatiskan beserta alasannya. • Draf: Alur otomasi berjalan untuk kasus normal. • Revisi: Kasus meragukan ditangani dengan pengecekan manusia, kegagalan tertangani, dan umpan balik reviewer ditindaklanjuti. • Final: Hasil satu minggu berjalan, perhitungan hemat waktu dan biaya, dan panduan singkat bagi rekan kerja.

Yang diserahkan: Tangkapan layar atau ekspor alur otomasi, peta proses sebelum dan sesudah, rekaman demo maksimal 5 menit, dan laporan satu halaman berisi hemat waktu dan biaya.

• Pemilihan dan pemetaan prosesbobot 25% · skor 0–4

  Proses dipetakan dengan jelas dan bagian yang diotomatiskan memang layak.

• Otomasi berjalanbobot 30% · skor 0–4

  Alur berjalan dengan data nyata atau realistis dan kasus normal terselesaikan tanpa campur tangan.

• Penanganan kasus meragukanbobot 25% · skor 0–4

  AI berhenti dan meminta pengecekan manusia saat ragu; kegagalan tidak hilang diam-diam.

• Dampak terukurbobot 20% · skor 0–4

  Hemat waktu dan biaya dihitung dengan jujur.

Modul 6 · Lapisan operasional produksi untuk satu aplikasi LLM: gerbang evaluasi, gateway, pemantauan, dan runbook

Ambil satu aplikasi LLM yang sudah berjalan dan siapkan untuk produksi. Anda menentukan sendiri target kualitas, latensi, dan biaya, lalu membuktikan sistem Anda menegakkannya. Simulasikan minimal dua insiden (penyedia model mati, dan kualitas turun setelah ganti prompt) dan tunjukkan bagaimana sistem Anda menanganinya. Tahapan pengerjaan • Kerangka: Target layanan (kualitas, latensi p95, biaya per permintaan), arsitektur operasional, rencana evaluasi, dan analisis biaya awal API vs model sendiri. • Draf: Gerbang evaluasi di CI berjalan, gateway dengan satu cadangan penyedia aktif, dan dasbor dasar. • Revisi: Model terbuka dilayani sendiri dan dibandingkan secara terukur, pemantauan kualitas aktif, dan umpan balik reviewer ditindaklanjuti. • Final: Simulasi dua insiden beserta buktinya, runbook, dan laporan keputusan akhir: apa yang Anda pilih dan berapa biayanya.

Yang diserahkan: Tautan repositori (konfigurasi CI, gateway, dan infrastruktur sebagai kode), tangkapan dasbor, runbook, dan laporan keputusan maksimal 4 halaman berisi tabel biaya dan latensi.

• Kualitas keputusan operasionalbobot 25% · skor 0–4

  Pilihan API vs model sendiri, cache, dan cadangan dibenarkan dengan angka biaya dan latensi, bukan selera.

• Gerbang evaluasi yang bermaknabobot 25% · skor 0–4

  Rilis yang menurunkan kualitas benar-benar terblokir; set uji mewakili penggunaan nyata.

• Ketahanan terhadap kegagalanbobot 20% · skor 0–4

  Insiden yang disimulasikan tertangani sesuai target; degradasi terkendali, tidak mati total.

• Observabilitasbobot 20% · skor 0–4

  Kualitas, latensi, token, dan biaya terlihat per fitur dan cukup untuk mendiagnosis insiden.

• Runbook dan dokumentasibobot 10% · skor 0–4

  Runbook bisa diikuti engineer lain yang tidak membangun sistem ini.

Pipeline CI/CD dengan gerbang keamanan berlapis dan deploy GitOps yang teruji memblokir

Bangun pipeline untuk aplikasi contoh (disediakan) atau aplikasi Anda sendiri. Buktikan setiap gerbang bekerja dengan menyiapkan merge request yang sengaja berbahaya: rahasia yang ter-commit, dependensi rentan, image dengan kerentanan kritis, dan IaC yang membuka akses publik. Tahapan pengerjaan • Kerangka: Desain pipeline, daftar gerbang beserta kebijakan blokir atau peringatan, dan alasannya. • Draf: Pipeline berjalan dengan pemindaian kode, rahasia, dan dependensi. • Revisi: Pemindaian kontainer dan IaC, deploy GitOps, dan umpan balik reviewer ditindaklanjuti. • Final: Empat merge request berbahaya terblokir dengan bukti, SBOM dan tanda tangan artefak, serta kebijakan pengecualian.

Yang diserahkan: Tautan repositori dengan konfigurasi pipeline, tautan ke empat merge request uji beserta hasil pipeline-nya, dan dokumen kebijakan keamanan pipeline maksimal 3 halaman.

• Gerbang yang terbukti bekerjabobot 35% · skor 0–4

  Keempat perubahan berbahaya benar-benar terblokir dengan pesan yang jelas bagi pengembang.

• Desain kebijakanbobot 25% · skor 0–4

  Keseimbangan antara memblokir dan memperingatkan dibenarkan; pengecualian punya proses dan tenggat.

• Rantai pasokbobot 20% · skor 0–4

  SBOM dihasilkan dan artefak ditandatangani serta diverifikasi saat deploy.

• Deploy GitOpsbobot 20% · skor 0–4

  Deploy deklaratif, bisa diaudit, dan bisa dikembalikan ke versi sebelumnya.