Mindflux: Sicherheit, Datenintegrität und Navigation härten
This commit is contained in:
AliceDarkest
@@ -0,0 +1,77 @@
|
||||
{
|
||||
"title": "Entwurfsmuster",
|
||||
"questions": [
|
||||
{
|
||||
"category": "Grundlagen",
|
||||
"hint": "Zweck von Entwurfsmustern.",
|
||||
"text": "Was ist ein Entwurfsmuster?",
|
||||
"answers": [
|
||||
"Eine bewährte, wiederverwendbare Lösungsschablone für ein häufiges Entwurfsproblem.",
|
||||
"Eine fertige Code-Bibliothek, die direkt eingebunden wird.",
|
||||
"Ein Werkzeug zur automatischen Codegenerierung aus UML-Diagrammen."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Ein Entwurfsmuster beschreibt eine Struktur und ihr Zusammenspiel – es ist kein fertiger Code, sondern eine Schablone."
|
||||
},
|
||||
{
|
||||
"category": "Singleton",
|
||||
"hint": "Genau eine Instanz.",
|
||||
"text": "Welches Merkmal gehört zwingend zum Singleton-Muster?",
|
||||
"answers": [
|
||||
"Ein öffentlicher Konstruktor, damit jede Klasse Instanzen erzeugen kann.",
|
||||
"Ein privater Konstruktor und eine statische Zugriffsmethode auf die einzige Instanz.",
|
||||
"Eine Liste von Beobachtern, die bei Änderungen benachrichtigt werden."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Der private Konstruktor verhindert Fremd-Instanziierung; getInstance() liefert immer dieselbe Instanz."
|
||||
},
|
||||
{
|
||||
"category": "Factory",
|
||||
"hint": "Objekterzeugung kapseln.",
|
||||
"text": "Welches Problem löst die Fabrikmethode (Factory)?",
|
||||
"answers": [
|
||||
"Sie sorgt dafür, dass Objekte automatisch gelöscht werden.",
|
||||
"Sie verschlüsselt die Kommunikation zwischen Objekten.",
|
||||
"Sie kapselt die Objekterzeugung, sodass der Client nur das Interface kennt."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Die Fabrik entscheidet, welche konkrete Klasse instanziiert wird – neue Varianten erfordern keine Änderung im Client-Code."
|
||||
},
|
||||
{
|
||||
"category": "Observer",
|
||||
"hint": "1:n-Abhängigkeit.",
|
||||
"text": "Wann ist das Observer-Muster die richtige Wahl?",
|
||||
"answers": [
|
||||
"Wenn mehrere Objekte automatisch über Zustandsänderungen eines Objekts informiert werden sollen.",
|
||||
"Wenn von einer Klasse nur eine einzige Instanz existieren darf.",
|
||||
"Wenn die Erzeugung von Objekten zentralisiert werden soll."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Das Subjekt benachrichtigt alle angemeldeten Beobachter – lose gekoppelt über ein gemeinsames Interface."
|
||||
},
|
||||
{
|
||||
"category": "MVC",
|
||||
"hint": "Drei Verantwortlichkeiten.",
|
||||
"text": "Welche Aufgabe hat der Controller im MVC-Muster?",
|
||||
"answers": [
|
||||
"Er speichert die Daten und enthält die Geschäftslogik.",
|
||||
"Er nimmt Benutzereingaben entgegen, ruft das Model auf und wählt die View.",
|
||||
"Er stellt die Daten grafisch für den Benutzer dar."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Model = Daten/Logik, View = Darstellung, Controller = Vermittler zwischen Eingabe, Model und View."
|
||||
},
|
||||
{
|
||||
"category": "MVC",
|
||||
"hint": "Vorteile der Trennung.",
|
||||
"text": "Welcher Vorteil ergibt sich direkt aus der MVC-Trennung?",
|
||||
"answers": [
|
||||
"Die Anwendung benötigt keine Datenbank mehr.",
|
||||
"Der Quellcode wird automatisch schneller ausgeführt.",
|
||||
"Oberfläche und Logik sind getrennt test- und austauschbar."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Durch die Trennung der Schichten lassen sich Views austauschen und Model-Logik isoliert testen."
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,77 @@
|
||||
{
|
||||
"title": "Hochverfügbarkeit",
|
||||
"questions": [
|
||||
{
|
||||
"category": "Grundlagen",
|
||||
"hint": "Die Neunen kennen.",
|
||||
"text": "Ein System hat eine Verfügbarkeit von 99,9 % pro Jahr. Wie viel Ausfallzeit entspricht das ungefähr?",
|
||||
"answers": [
|
||||
"Rund 8,8 Stunden pro Jahr.",
|
||||
"Rund 3,65 Tage pro Jahr.",
|
||||
"Rund 53 Minuten pro Jahr."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "0,1 % von 8760 Stunden sind rund 8,76 Stunden. 3,65 Tage gehören zu 99 %, 53 Minuten zu 99,99 %."
|
||||
},
|
||||
{
|
||||
"category": "Grundlagen",
|
||||
"hint": "Kritische Einzelkomponenten.",
|
||||
"text": "Was ist ein Single Point of Failure (SPOF)?",
|
||||
"answers": [
|
||||
"Eine Komponente, die doppelt ausgelegt ist und darum nie ausfällt.",
|
||||
"Eine Komponente, deren Ausfall das gesamte System zum Stillstand bringt.",
|
||||
"Der zentrale Monitoring-Server eines Rechenzentrums."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Ein SPOF ist jede nicht redundante Komponente, an der das Gesamtsystem hängt – Ziel ist, SPOFs durch Redundanz zu eliminieren."
|
||||
},
|
||||
{
|
||||
"category": "Redundanz",
|
||||
"hint": "RAID richtig einordnen.",
|
||||
"text": "Warum ersetzt ein RAID kein Backup?",
|
||||
"answers": [
|
||||
"Weil RAID nur bei SSDs funktioniert, Backups aber auf Festplatten liegen.",
|
||||
"Weil RAID die Daten komprimiert und dadurch Datenverlust entsteht.",
|
||||
"Weil versehentlich gelöschte oder verschlüsselte Daten sofort auf allen Platten betroffen sind."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "RAID schützt gegen Hardware-Ausfall einzelner Platten. Logische Fehler (Löschen, Ransomware) treffen alle Kopien gleichzeitig – dagegen hilft nur ein Backup."
|
||||
},
|
||||
{
|
||||
"category": "Redundanz",
|
||||
"hint": "Cluster-Betriebsarten.",
|
||||
"text": "Was kennzeichnet einen Aktiv/Passiv-Failover-Cluster?",
|
||||
"answers": [
|
||||
"Ein Standby-Server übernimmt automatisch, wenn der aktive Server ausfällt.",
|
||||
"Beide Server bearbeiten dauerhaft gemeinsam die Last.",
|
||||
"Die Server sichern sich gegenseitig täglich per Backup."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Beim Aktiv/Passiv-Cluster steht der zweite Knoten bereit und übernimmt beim Ausfall (Failover). Aktiv/Aktiv verteilt dagegen die Last auf beide."
|
||||
},
|
||||
{
|
||||
"category": "RTO & RPO",
|
||||
"hint": "Zeit vs. Datenverlust.",
|
||||
"text": "Welche Aussage zu RTO und RPO ist korrekt?",
|
||||
"answers": [
|
||||
"RTO begrenzt den maximalen Datenverlust, RPO die Wiederherstellungszeit.",
|
||||
"RTO begrenzt die maximale Wiederherstellungszeit, RPO den maximalen Datenverlust.",
|
||||
"RTO und RPO bezeichnen dasselbe und sind austauschbar."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "RTO = wie lange darf die Wiederherstellung dauern; RPO = wie alt darf der letzte Datenstand sein (bestimmt die Backup-Frequenz)."
|
||||
},
|
||||
{
|
||||
"category": "RTO & RPO",
|
||||
"hint": "Backup-Frequenz ableiten.",
|
||||
"text": "Ein Unternehmen definiert einen RPO von 1 Stunde. Was folgt daraus?",
|
||||
"answers": [
|
||||
"Das System muss nach einem Ausfall innerhalb 1 Stunde wieder laufen.",
|
||||
"Die USV muss das System mindestens 1 Stunde überbrücken.",
|
||||
"Die Daten müssen mindestens stündlich gesichert bzw. repliziert werden."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Der RPO begrenzt den maximal tolerierten Datenverlust – bei 1 Stunde RPO darf der letzte Sicherungsstand höchstens 1 Stunde alt sein."
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user