diff --git a/content/day1/03_operator-mistakes.md b/content/day1/03_operator-mistakes.md
index 72ba35a..417e6ea 100644
--- a/content/day1/03_operator-mistakes.md
+++ b/content/day1/03_operator-mistakes.md
@@ -66,4 +66,13 @@ tags:
     - But controller runtime abstracts the patch source so you have to compare before and after state yourself - but you should not do that
 - What about state sharing across multiple threads?
     - Controller runtime handels each reconcile as idempotent, so you can just multithread
-    - But handling consistency can still be hard
\ No newline at end of file
+    - But handling consistency can still be hard because you have to design all of your operations as idempotent by rebuilding the state each time
+- What are your thoughts on controllers that do stuff in the real world (especially b/c it takes longer and there are no natie observers)
+    - Do something like the krt project by keeping the state seperatly
+- What if someone changes things at the cloud provider
+    - A question of philosophy -> Usually just treat the operator at the source of throuth
+- How do you test your operators?
+    - Depends on your output (kubernetes objects make stuf simple)
+    - For cilium: Simple b/c it's just creating kubernetes projects
+    - With oputside interaction: In-memory state representation or mocking
+    - For complex controllers split the operator into: Ingestion, data model and transformation 
\ No newline at end of file