Petunjuk dan konteks
Bangun layanan objek WORM multi-tenant. Objek diberi versi, dapat memiliki periode retensi tetap, dan dapat dilindungi tanpa batas waktu oleh legal hold. Pelanggan memerlukan penolakan penghapusan dan penimpaan selama masa retensi, mode tata kelola dan kepatuhan, serta jalur audit yang tidak dapat dilewati oleh administrator, replikasi, atau pembersihan siklus hidup (lifecycle cleanup). Jelaskan alur penulisan, pembacaan, penghapusan, replikasi, pemulihan, dan audit.
Hal yang diuji oleh pewawancara
- Apakah Anda membedakan versi objek, periode retensi, mode tata kelola, mode kepatuhan, dan legal hold.
- Apakah immutability ditegakkan oleh eksekusi penyimpanan dan bukan oleh konvensi klien.
- Apakah Anda merancang izin, bypass tata kelola, batasan akun root, dan persetujuan ganda (dual approval).
- Apakah Anda menangani replikasi, percobaan ulang (retries), penanda penghapusan (delete markers), dan konsistensi jam.
- Apakah setiap perubahan kebijakan dan penolakan dapat diaudit secara terbukti.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah kebijakan ditentukan oleh bucket, awalan (prefix), versi objek, atau kontrak tenant?
- Haruskah mode kepatuhan mencegah penghapusan oleh akun root sebelum masa berlaku berakhir?
- Siapa yang memulai, menghapus, dan menyetujui legal hold, dan apakah persetujuan empat mata (four-eyes approval) diperlukan?
- Haruskah replika mempertahankan status kunci dan tanggal, dan berapa jeda (lag) lintas wilayah yang dapat diterima?
- Apakah klien memerlukan pembacaan yang konsisten kuat (strongly consistent reads), daftar versi, ekspor bukti, atau hanya penolakan penghapusan?
Jawaban 30 detik
“Saya akan memisahkan data objek, indeks versi, dan kebijakan retensi sambil melakukan commit terhadap status mereka secara atomik. Operasi tulis membuat versi yang immutable; mesin kebijakan menghitung retainUntil, mode, dan status legal hold, dan setiap jalur penghapusan memeriksa fakta-fakta tersebut di dalam batas otorisasi yang sama. Mode tata kelola mengizinkan bypass yang diotorisasi secara eksplisit, sedangkan mode kepatuhan menolak setiap penghapusan sebelum masa berlaku berakhir; legal hold tidak memiliki tanggal dan hanya dapat dihapus melalui alur kerja persetujuan. Replikasi membawa metadata versi dan penguncian. Penulisan, penghapusan yang ditolak, bypass, dan perubahan kebijakan masuk ke log audit append-only yang dapat menghasilkan bukti.”
Pembahasan mendalam langkah demi langkah
1. Modelkan versi dan status penguncian
Kunci objek bukanlah entitas yang dilindungi; melainkan objectVersionId. Simpan digest konten, waktu penulisan, retainUntil, mode, legal hold, tenant, dan versi kebijakan. Penghapusan sederhana membuat delete marker alih-alih menghapus versi yang dilindungi secara fisik; penghapusan permanen harus menyebutkan versi dan lolos pemeriksaan penguncian.
2. Rancang penulisan dan retensi default
Kebijakan bucket atau tenant dapat memberikan mode dan durasi default, sementara operasi tulis dapat meminta nilai tingkat objek. Validasi durasi maksimum, sumber waktu, dan izin, lalu ikat metadata yang dihitung secara atomik ke versi tersebut. Perubahan kebijakan memengaruhi versi di masa mendatang dan tidak dapat mempersingkat retensi yang ada secara retroaktif.
{
"objectVersionId": "v_91c2",
"retention": {"mode": "COMPLIANCE", "retainUntil": "2027-01-01T00:00:00Z"},
"legalHold": "OFF",
"policyVersion": 18
}3. Terapkan gerbang penghapusan dan penimpaan
Penghapusan, penimpaan, pengurangan masa retensi, dan pelepasan legal hold menggunakan satu layanan otorisasi. Layanan ini membaca versi terbaru dan secara bersyarat memeriksa waktu, mode, izin principal, dan status penahanan. Mode tata kelola memerlukan izin bypass eksplisit dan penanda permintaan; mode kepatuhan menolak semua penghapusan sebelum masa berlaku berakhir, termasuk oleh administrator. Penolakan mengembalikan error yang stabil dan ID audit.
4. Rancang legal hold dan persetujuan
Legal hold tidak bergantung pada retensi dan melindungi versi hingga dihapus secara eksplisit. Alur kerja penghapusan mengikat kasus atau kontrak, alasan, pelaku, penyetuju, dan autentikasi bertingkat (step-up authentication); tenant berisiko tinggi dapat mewajibkan dua orang. Setelah dihapus, retainUntil yang belum kedaluwarsa tetap melindungi versi tersebut, sehingga legal hold bukanlah pengganti retensi.
5. Tangani replikasi, pemulihan, dan jam
Replikasi mentransfer konten, ID versi, digest, dan metadata penguncian lengkap; target memverifikasi tanda tangan sumber dan versi kebijakan sebelum melakukan commit. Sumber terus menolak penghapusan hingga target mengonfirmasinya, dan target tidak dapat mengklaim kepatuhan sebelum verifikasi kunci dilakukan. Pemulihan membuat versi baru dan tidak pernah memutasi versi lama. Bandingkan tanggal menggunakan layanan waktu terkontrol dan stempel waktu audit monotonik, bukan jam mesin tunggal.
6. Bangun audit dan bukti
Audit operasi tulis, pembuatan versi, penghapusan yang berhasil atau ditolak, bypass, perubahan legal hold, konfirmasi replikasi, dan publikasi kebijakan. Simpan event dalam log terpisah yang bersifat append-only dengan rantai hash atau tanda tangan serta akses kueri yang dibatasi. Ekspor inventaris versi, status penguncian, dan digest audit secara berkala sehingga pelanggan dapat membuktikan perlindungan pada titik waktu tertentu.
Contoh jawaban yang kuat
“Saya memperlakukan metadata versi dan penguncian sebagai fakta yang immutable, dan setiap jalur penghapusan membaca status terkini serta melakukan pemeriksaan bersyarat. Saat penulisan, mesin kebijakan menghitung retensi, mode, dan legal hold lalu mengikatnya secara atomik ke versi tersebut. Mode tata kelola memungkinkan bypass yang diotorisasi secara eksplisit; mode kepatuhan menolak semua penghapusan sebelum kedaluwarsa. Legal hold hanya dapat dicabut dengan adanya kasus, alasan, dan persetujuan. Replikasi membawa versi, digest, dan metadata penguncian, serta baru dinyatakan patuh setelah adanya konfirmasi dari target. Penolakan, bypass, perubahan kebijakan, dan replikasi masuk ke log audit bertanda tangan append-only, yang dari sana klien dapat mengekspor inventaris versi dan digest bukti.”
Kesalahan umum
- Memeriksa kunci hanya pada lapisan API → jalur pembersihan atau replikasi dapat melewatinya → periksa kembali pada eksekusi penghapusan penyimpanan.
- Menerapkan perubahan kebijakan bucket ke versi lama → retensi yang ada dapat dipersingkat secara ilegal → buat versi kebijakan dan hanya pengaruhi penulisan di masa mendatang.
- Memperlakukan legal hold sebagai tanggal tetap → penghapusan otomatis setelah kedaluwarsa dapat melanggar proses hukum suatu kasus → jaga hold tetap independen dengan pencabutan eksplisit.
- Membuat bypass tata kelola secara implisit → penyalahgunaan hak istimewa tidak dapat dijelaskan → wajibkan izin eksplisit, penanda, dan audit persetujuan.
- Menyatakan kepatuhan saat replikasi baru dikirimkan → target mungkin kehilangan metadata penguncian → konfirmasikan versi target dan status penguncian terlebih dahulu.
Pertanyaan lanjutan dan tanggapan
Mengapa DELETE sederhana dapat berhasil tanpa menghapus versi?
Dengan objek berversi, DELETE sederhana dapat membuat delete marker baru yang menyembunyikan versi saat ini sementara versi yang dilindungi tetap ada. Penghapusan permanen harus menentukan ID versi dan melewati gerbang penguncian.
Mengapa mode kepatuhan membutuhkan batasan akun yang lebih ketat?
Artinya tidak ada principal, termasuk akun root atau administrator penyimpanan, yang dapat menghapus sebelum tanggal retensi. Penghapusan harus diisolasi dari izin superuser IAM biasa agar peran dengan hak istimewa tidak dapat membatalkan kepatuhan.
Bagaimana Anda membuktikan bahwa penghapusan yang ditolak tidak hilang dari audit?
Gunakan satu ID permintaan untuk keputusan otorisasi, status versi, dan event audit, lalu tulis event tersebut ke log append-only terpisah. Rekonsiliasikan permintaan penghapusan, inventaris versi, dan event penolakan secara berkala, serta bekukan operasi berisiko tinggi jika terdapat selisih.
Bolehkah sumber dihapus saat replikasi tertunda?
Tidak. Kunci sumber tetap ada hingga target mengonfirmasi digest konten, ID versi, dan metadata retensi; jika tidak, kegagalan replikasi akan menciptakan celah tanpa salinan yang patuh.