08. Quiz

Lernziele

Nach diesem Kapitel können Sie: - Ihr Wissen zu allen Kapiteln dieses Moduls überprüfen - Ihre Verständnislücken identifizieren - Sich auf die Prüfung vorbereiten

Lesezeit

ca. 30-45 Minuten

Quiz: Strategische Planung in IT-Projekten

Dieses Quiz umfasst 15 Fragen, die alle 7 Kapitel dieses Moduls abdecken. Nutzen Sie es zur Selbstüberprüfung und zur Vorbereitung auf Prüfungen.

Frage 1: Planungsgrundlagen

Ein Kunde möchte ein neues IT-Projekt starten und fordert, dass Sie sofort mit der Projektplanung (Zeitplan, Ressourcen, Budget) beginnen, obwohl das Produktkonzept noch vage und die technischen Anforderungen unklar sind. Warum ist dies aus Beratersicht kritisch zu bewerten?

A) Dies ist unkritisch, da die Projektplanung parallel zur Produktplanung erfolgen kann und die Schätzungen später angepasst werden können.

B) Dies ist kritisch, da die Projektplanung auf einem stabilen Produktkonzept aufbauen sollte. Ohne klare Anforderungen sind Schätzungen unzuverlässig und besteht das Risiko, "das Falsche richtig zu bauen".

C) Dies ist nur kritisch, wenn das Projekt groß ist. Für kleine Projekte kann die Projektplanung sofort beginnen.

D) Dies ist kritisch, aber die Projektplanung kann beginnen, solange ein grober Zeitplan erstellt wird.

Lösung: Frage 1

B) Dies ist kritisch, da die Projektplanung auf einem stabilen Produktkonzept aufbauen sollte. Ohne klare Anforderungen sind Schätzungen unzuverlässig und besteht das Risiko, "das Falsche richtig zu bauen".

Erklärung: - Die Projektplanung baut auf den Ergebnissen der Produktplanung auf - Ohne stabilisiertes Produktkonzept sind Schätzungen zu Zeit und Kosten höchst unzuverlässig - Es besteht das Risiko, "das Falsche richtig zu bauen" (Building the wrong thing right) - Dies kann zu massiven Nacharbeiten, Budgetüberschreitungen oder Projekterfolg führen

Frage 2: Soll-Konzept vs. Lösungskonzept

Welches Dokument ist primär "technologieoffen" und welches ist "technologiefixiert"? Nennen Sie jeweils ein Beispiel für den Inhalt.

A) Soll-Konzept ist technologiefixiert, Lösungskonzept ist technologieoffen. Beispiel Soll-Konzept: "Einsatz von Java Spring Boot". Beispiel Lösungskonzept: "Automatisierung der Rechnungsverarbeitung".

B) Soll-Konzept ist technologieoffen, Lösungskonzept ist technologiefixiert. Beispiel Soll-Konzept: "Automatisierung der Rechnungsverarbeitung". Beispiel Lösungskonzept: "Einsatz von Java Spring Boot".

C) Beide Dokumente sind technologieoffen. Beispiel Soll-Konzept: "Automatisierung der Rechnungsverarbeitung". Beispiel Lösungskonzept: "Skalierbare Server-Architektur".

D) Beide Dokumente sind technologiefixiert. Beispiel Soll-Konzept: "Einsatz von Java Spring Boot". Beispiel Lösungskonzept: "Einsatz von PostgreSQL".

Lösung: Frage 2

B) Soll-Konzept ist technologieoffen, Lösungskonzept ist technologiefixiert. Beispiel Soll-Konzept: "Automatisierung der Rechnungsverarbeitung". Beispiel Lösungskonzept: "Einsatz von Java Spring Boot".

Erklärung: - Soll-Konzept (Fachkonzept): Beschreibt den gewünschten Zielzustand aus fachlicher Sicht. Es ist technologieoffen. Beispiel: "Der Prozess der Rechnungsprüfung soll automatisiert erfolgen." - Lösungskonzept (Umsetzungskonzept): Dies ist der detaillierte technische Bauplan. Es ist technologiefixiert. Beispiel: "Einsatz von Java Spring Boot mit einer SQL-Datenbank auf Azure-VMs."

Frage 3: STRIDE-Modell

Führen Sie eine STRIDE-Analyse für ein Online-Banking-System durch. Ordnen Sie jede STRIDE-Kategorie (S, T, R, I, D, E) einem Beispiel für eine Bedrohung und einer Gegenmaßnahme zu.

A) S (Spoofing): Angreifer manipuliert Transaktionen → Verschlüsselung. T (Tampering): Angreifer gibt sich als Bankkunde aus → MFA. R (Repudiation): Kunden bestreiten Transaktionen → Audit-Logs. I (Information Disclosure): Angreifer erhält Zugriff auf Bankdaten → Verschlüsselung. D (Denial of Service): Angreifer eskaliert Rechte → Rate Limiting. E (Elevation of Privilege): Angreifer überlastet das System → Principle of Least Privilege.

B) S (Spoofing): Angreifer gibt sich als Bankkunde aus → MFA. T (Tampering): Angreifer manipuliert Transaktionen → Serverseitige Validierung. R (Repudiation): Kunden bestreiten Transaktionen → Audit-Logs. I (Information Disclosure): Angreifer erhält Zugriff auf Bankdaten → Verschlüsselung. D (Denial of Service): Angreifer überlastet das System → Rate Limiting. E (Elevation of Privilege): Angreifer eskaliert Rechte → Principle of Least Privilege.

C) S (Spoofing): Angreifer manipuliert Transaktionen → MFA. T (Tampering): Angreifer gibt sich als Bankkunde aus → Serverseitige Validierung. R (Repudiation): Angreifer erhält Zugriff auf Bankdaten → Audit-Logs. I (Information Disclosure): Kunden bestreiten Transaktionen → Verschlüsselung. D (Denial of Service): Angreifer eskaliert Rechte → Rate Limiting. E (Elevation of Privilege): Angreifer überlastet das System → Principle of Least Privilege.

D) Alle STRIDE-Kategorien sind identisch, daher ist die Zuordnung irrelevant.

Lösung: Frage 3

B) S (Spoofing): Angreifer gibt sich als Bankkunde aus → MFA. T (Tampering): Angreifer manipuliert Transaktionen → Serverseitige Validierung. R (Repudiation): Kunden bestreiten Transaktionen → Audit-Logs. I (Information Disclosure): Angreifer erhält Zugriff auf Bankdaten → Verschlüsselung. D (Denial of Service): Angreifer überlastet das System → Rate Limiting. E (Elevation of Privilege): Angreifer eskaliert Rechte → Principle of Least Privilege.

Erklärung: - S (Spoofing): Identitätsfälschung. Angreifer gibt sich als authentifizierter Bankkunde aus. Gegenmaßnahme: Multi-Faktor-Authentifizierung (MFA). - T (Tampering): Manipulation von Daten. Angreifer manipuliert Transaktionen. Gegenmaßnahme: Serverseitige Validierung aller Transaktionen. - R (Repudiation): Nichtanerkennung von Handlungen. Kunden bestreiten Transaktionen. Gegenmaßnahme: Umfassende Audit-Logs mit Zeitstempeln, IP-Adressen, etc. - I (Information Disclosure): Offenlegung von Informationen. Angreifer erhält Zugriff auf Bankdaten. Gegenmaßnahme: Verschlüsselung (At Rest & In Transit). - D (Denial of Service): Dienstverweigerung. Angreifer überlastet das System. Gegenmaßnahme: Rate Limiting, DDoS-Schutz, Auto-Scaling. - E (Elevation of Privilege): Privilegieneskalation. Angreifer eskaliert Rechte. Gegenmaßnahme: Principle of Least Privilege, Code-Reviews für Rechte-Checks.

Frage 4: CAPEX vs. OPEX

Ein Unternehmen plant die Umstellung seiner IT-Infrastruktur von On-Premise auf Cloud. Welche Kosten sinken (Verringerung des OPEX) und welche steigen (neue OPEX)?

A) Kosten sinken: Hardware-Energie & Kühlung, Hardware-Instandhaltung. Kosten steigen: Cloud-Miete, Cloud-Support, Datentransferkosten, Training.

B) Kosten sinken: Cloud-Miete, Cloud-Support. Kosten steigen: Hardware-Energie & Kühlung, Hardware-Instandhaltung.

C) Alle Kosten steigen bei der Cloud-Migration.

D) Alle Kosten sinken bei der Cloud-Migration.

Lösung: Frage 4

A) Kosten sinken: Hardware-Energie & Kühlung, Hardware-Instandhaltung. Kosten steigen: Cloud-Miete, Cloud-Support, Datentransferkosten, Training.

Erklärung: Kosten, die sinken: - Hardware-Energie & Kühlung (Server in Cloud-Datacenter, keine lokalen Energiekosten) - Hardware-Instandhaltung (Hardware vom Cloud-Provider gewartet) - Rechenzentrum-Management (Raum, Sicherheit)

Kosten, die steigen: - Cloud-Miete (IaaS, PaaS, SaaS) - Cloud-Support & Managed Services - Datentransferkosten (Egress-Gebühren) - Training & Cloud-Skills - Compliance & Governance (Cloud-spezifische Anforderungen)

Frage 5: ROI-Berechnung

Ein CRM-System soll eingeführt werden. Investition (CAPEX): €200.000. OPEX pro Jahr: €25.000. Erwarteter Nutzen (Business Value) pro Jahr: €80.000. Wie hoch ist der ROI über 5 Jahre?

A) ROI = 23,08% B) ROI = 300% C) ROI = 674% D) ROI = 100%

Lösung: Frage 5

A) ROI = 23,08%

Berechnung:

Schritt 1: Gesamtkosten über 5 Jahre berechnen - CAPEX: €200.000 (Jahr 0) - OPEX über 5 Jahre: 5 × €25.000 = €125.000 - Gesamtkosten: €200.000 + €125.000 = €325.000

Schritt 2: Gesamtnutzen über 5 Jahre berechnen - Nutzen pro Jahr: €80.000 - Gesamtnutzen über 5 Jahre: 5 × €80.000 = €400.000

Schritt 3: ROI berechnen ROI = (Gesamtnutzen - Gesamtkosten) / Gesamtkosten × 100%

\[ROI = \frac{€400.000 - €325.000}{€325.000} \times 100\% = 23,08\%\]

Erklärung: - ROI von 23,08% ist moderat (Branchenziel: oft > 50% für IT-Projekte) - Das Projekt ist profitabel (ROI > 0) - Payback Period: Zwischen Jahr 3 und Jahr 4 (ca. 3,6 Jahre)

Frage 6: AKV-Prinzip

Ein Projektleiter ist für das Einhalten des Projektbudgets verantwortlich, hat aber keine Entscheidungsbefugnis für Budget- oder Personalentscheidungen. Analysieren Sie diese Situation nach dem AKV-Prinzip.

A) A < K (Aufgabe kleiner als Kompetenz). Der Projektleiter hat zu viele Befugnisse für seine Aufgaben. B) K < V (Kompetenz kleiner als Verantwortung). Der Projektleiter ist für das Ergebnis verantwortlich, hat aber keine notwendigen Befugnisse. C) V < A (Verantwortung kleiner als Aufgabe). Der Projektleiter hat Aufgaben, aber keine klare Verantwortung. D) Es besteht ein kongruentes Verhältnis (K = V), da der Projektleiter Aufgaben und Verantwortung hat.

Lösung: Frage 6

B) K < V (Kompetenz kleiner als Verantwortung). Der Projektleiter ist für das Ergebnis verantwortlich, hat aber keine notwendigen Befugnisse.

Erklärung: - Aufgabe (A): Projektbudget einhalten, Ressourcen steuern - Kompetenz (K): Keine Budget- oder Personalentscheidungsbefugnis - Verantwortung (V): Für das Einhalten des Projektbudgets verantwortlich

Ergebnis: K < V (Kompetenz kleiner als Verantwortung)

Konsequenzen: - Handlungsunfähigkeit (Der Projektleiter kann Budget-Engpässe nicht beheben) - Frustration (Der Projektleiter wird für Ergebnisse zur Rechenschaft gezogen, die er nicht steuern kann) - Konflikte (Mit C-Level oder Department-Managern, die die Entscheidungen treffen) - Risiko (Budgetüberschreitungen oder Projekterfolg gefährdet)

Frage 7: RACI-Matrix

In einem Projekt wird für die Aufgabe "Genehmigung des Architekturkonzepts" sowohl der CTO als auch der CIO als Accountable (A) in der RACI-Matrix eingetragen. Warum ist dies methodisch falsch?

A) Dies ist nicht falsch. Bei kritischen Entscheidungen können mehrere Personen Accountable sein. B) Dies ist falsch, da jede Aufgabe genau ein A (Accountable) haben muss. Mehrere As führen zu Verantwortungsdiffusion. C) Dies ist falsch, da Accountable nur eine Person sein kann, aber Consulted (C) und Informed (I) können beliebig viele sein. D) Dies ist falsch, da CTO und CIO unterschiedliche Hierarchiestufen haben.

Lösung: Frage 7

B) Dies ist falsch, da jede Aufgabe genau ein A (Accountable) haben muss. Mehrere As führen zu Verantwortungsdiffusion.

Erklärung: Die RACI-Matrix erfordert, dass jede Aufgabe genau ein A (Accountable) hat. Das ist eine grundlegende Regel des RACI-Standards.

Probleme bei mehreren Accountables: - Verantwortungsdiffusion: Niemand fühlt sich allein verantwortlich ("Der andere wird es schon machen") - Konflikte: Unterschiedliche Meinungen führen zu Konflikten und Entscheidungsstau - Unklare Zuständigkeit: Mitarbeiter wissen nicht, wem sie folgen müssen - Verzögerungen: Entscheidungsprozesse verlangsamen sich - Accountability-Problem: Im Fehlerfall kann niemand eindeutig zur Rechenschaft gezogen werden

Frage 8: Szenariobildung

Ein Unternehmen plant die Einführung eines neuen HR-Portals. Erstellen Sie drei Szenarien (Best Case, Realistisch, Worst Case) und vergleichen Sie diese hinsichtlich Kosten, Zeit und Risiko.

A) Best Case: €80.000, 4 Monate, Geringes Risiko. Realistisch: €100.000, 6 Monate, Mittleres Risiko. Worst Case: €150.000, 9 Monate, Hohes Risiko.

B) Best Case: €150.000, 9 Monate, Hohes Risiko. Realistisch: €100.000, 6 Monate, Mittleres Risiko. Worst Case: €80.000, 4 Monate, Geringes Risiko.

C) Best Case: €100.000, 6 Monate, Mittleres Risiko. Realistisch: €100.000, 6 Monate, Mittleres Risiko. Worst Case: €100.000, 6 Monate, Mittleres Risiko.

D) Szenarien sind nicht sinnvoll, da man nicht in die Zukunft blicken kann.

Lösung: Frage 8

A) Best Case: €80.000, 4 Monate, Geringes Risiko. Realistisch: €100.000, 6 Monate, Mittleres Risiko. Worst Case: €150.000, 9 Monate, Hohes Risiko.

Erklärung:

Szenario 1: Best Case (Optimistisch) - Annahmen: Alle Stakeholder sind voll einverstanden, keine technischen Probleme, Anforderungen ändern sich nicht - Kosten: €80.000 (unter dem Budget) - Zeit: 4 Monate (unter der Planung) - Risiko: Gering

Szenario 2: Realistisch (Base Case) - Annahmen: Normale Stakeholder-Einbindung, typische technische Herausforderungen, Anforderungen ändern sich moderat - Kosten: €100.000 (entspricht dem Budget) - Zeit: 6 Monate (entspricht der Planung) - Risiko: Mittel

Szenario 3: Worst Case (Pessimistisch) - Annahmen: Stakeholder-Widerstand, schwere technische Probleme, Anforderungen ändern sich signifikant - Kosten: €150.000 (50% über dem Budget) - Zeit: 9 Monate (3 Monate Verzögerung) - Risiko: Hoch

Szenarien helfen, Ungewissheit zu managen und das Projekt unter verschiedenen Bedingungen zu testen.

Frage 9: Komponentensteckbrief

Welche Informationen sollten im Abschnitt "Nicht-funktionale Anforderungen" eines Komponentensteckbriefs enthalten sein? Nennen Sie konkrete Beispiele.

A) Nur technische Details wie Programmiersprache und Framework. B) Nur Geschäftliche Anforderungen wie "Erhöhung der Conversion Rate". C) Qualitätsmerkmale wie Performance, Sicherheit, Verfügbarkeit, Skalierbarkeit mit konkreten Beispielen (z.B. "Response Time P95 < 500 ms", "OAuth 2.0", "99.9% Uptime"). D) Nur Team-Informationen und Verantwortlichkeiten.

Lösung: Frage 9

C) Qualitätsmerkmale wie Performance, Sicherheit, Verfügbarkeit, Skalierbarkeit mit konkreten Beispielen (z.B. "Response Time P95 < 500 ms", "OAuth 2.0", "99.9% Uptime").

Erklärung: Nicht-funktionale Anforderungen (NFRs) beschreiben, WIE das System funktionieren soll, nicht WAS es tut.

Beispiele für NFRs:

Performance: - Response Time P95 < 500 ms - Throughput: 10.000 Requests/Minute - Concurrency: 1.000 gleichzeitige Benutzer

Sicherheit: - Authentifizierung: OAuth 2.0 mit JWT - Autorisierung: RBAC (Admin, User, Guest) - Verschlüsselung: AES-256 At Rest, TLS 1.3 In Transit - DSGVO-Compliance

Verfügbarkeit: - Uptime: 99.9% (max. 43,2 Minuten Ausfall pro Monat) - Redundanz: Multi-AZ Deployment

Skalierbarkeit: - Horizontal Scaling: Auto-Scaling - Vertical Scaling: Größere Instanzen

Frage 10: Schnittstellenkatalog

Ein E-Commerce-System besteht aus Webshop, Order-Service, Payment-Service, User-Service, Product-Service. Welche Informationen sollten in einem Schnittstellenkatalog enthalten sein?

A) Nur die Endpunkte (URLs) der REST-APIs. B) ID, Name, Typ, Konsument, Provider, Zweck, Endpunkt, Methoden, Authentifizierung, Request-Format, Response-Format, Rate Limiting, SLA, Version, Dokumentation, Kontakt. C) Nur die Authentifizierungs-Methode. D) Nur die Kosten für die Schnittstellen.

Lösung: Frage 10

B) ID, Name, Typ, Konsument, Provider, Zweck, Endpunkt, Methoden, Authentifizierung, Request-Format, Response-Format, Rate Limiting, SLA, Version, Dokumentation, Kontakt.

Erklärung: Ein Schnittstellenkatalog (Interface Catalog) sollte umfassende Informationen enthalten:

Feld	Beschreibung
ID	Eindeutige Identifikation der Schnittstelle
Name	Name der Schnittstelle
Typ	Art der Schnittstelle (REST, GraphQL, gRPC, Message Queue, etc.)
Konsument	Wer nutzt die Schnittstelle?
Provider	Wer stellt die Schnittstelle bereit?
Zweck	Warum wird die Schnittstelle benötigt?
Endpunkt	URL oder Pfad
Methoden	HTTP-Methoden (GET, POST, PUT, DELETE, etc.)
Authentifizierung	Wie wird authentifiziert?
Request-Format	Format der Anfrage
Response-Format	Format der Antwort
Rate Limiting	Begrenzung der Anfragerate
SLA	Service Level Agreement
Version	Version der Schnittstelle
Dokumentation	Link zur Dokumentation
Kontakt	Ansprechpartner bei Problemen

Frage 11: Projektstrukturplan (PSP/WBS)

Ein Unternehmen plant die Entwicklung eines neuen CRM-Systems. Welche Phasen sollten im Projektstrukturplan enthalten sein?

A) Nur die Entwicklungsphase. B) Vorstudie, Konzeption, Entwicklung, Test & Go-Live. C) Nur Test & Go-Live. D) Nur Vorstudie.

Lösung: Frage 11

B) Vorstudie, Konzeption, Entwicklung, Test & Go-Live.

Erklärung: Ein Projektstrukturplan (PSP) / Work Breakdown Structure (WBS) sollte alle Phasen des Projekts enthalten:

Phase 1: Vorstudie - Ist-Analyse - Anforderungserhebung - Soll-Konzept - Vorstudie-Review

Phase 2: Konzeption - Architektur-Design - UI/UX-Design - Datenbank-Design - API-Design

Phase 3: Entwicklung - Backend-Entwicklung - Frontend-Entwicklung - Integrationen

Phase 4: Test & Go-Live - Unit-Testing - Integration-Testing - System-Testing - UAT - Go-Live

Frage 12: DSGVO-Compliance

Ein E-Commerce-Unternehmen plant die Speicherung von Kundendaten (Name, Adresse, E-Mail, Bestellhistorie, Zahlungsdaten). Welche DSGVO-Anforderungen müssen berücksichtigt werden?

A) Nur die Speicherung der Daten. B) Recht auf Information, Recht auf Löschung, Recht auf Berichtigung, Datenschutz durch Technik, Verschlüsselung, Zugriffsrechte, Datenexport-Funktion, Meldung von Datenpannen. C) Nur die Verschlüsselung der Daten. D) DSGVO ist für E-Commerce-Unternehmen nicht relevant.

Lösung: Frage 12

B) Recht auf Information, Recht auf Löschung, Recht auf Berichtigung, Datenschutz durch Technik, Verschlüsselung, Zugriffsrechte, Datenexport-Funktion, Meldung von Datenpannen.

Erklärung: Die DSGVO (Datenschutz-Grundverordnung) fordert:

Rechte der Betroffenen: - Recht auf Information (Art. 13): Datenschutzerklärung, Cookie-Banner - Recht auf Löschung ("Recht auf Vergessen", Art. 17): Datenlöschungs-Mechanismus - Recht auf Berichtigung (Art. 16): UI für Datenänderung - Recht auf Datenportabilität (Art. 20): Datenexport-Funktion

Technische Anforderungen: - Datenschutz durch Technik (Privacy by Design, Art. 25) - Verschlüsselung personenbezogener Daten (At Rest + In Transit) - Zugriffsrechte und Zugriffskontrolle (RBAC, Audit-Logs) - Datenminimierung: Nur notwendige Daten erheben

Organisatorische Anforderungen: - Meldung von Datenpannen innerhalb von 72 Stunden (Art. 33) - Auftragsverarbeitungsverträge (AVV) mit Cloud-Providern - Datenschutz-Folgenabschätzung (DPIA) bei hohem Risiko

Frage 13: NPV vs. ROI

Warum wird NPV (Net Present Value) anstelle von ROI (Return on Investment) für komplexe, langfristige Investitionsentscheidungen bevorzugt?

A) ROI ist einfacher zu berechnen als NPV. B) NPV berücksichtigt den Zeitwert des Geldes (Diskontierung), ROI ignoriert diesen. NPV ist daher präziser für langfristige Projekte. C) NPV und ROI sind identisch, daher ist es egal, welchen man verwendet. D) ROI ist besser für langfristige Projekte.

Lösung: Frage 13

B) NPV berücksichtigt den Zeitwert des Geldes (Diskontierung), ROI ignoriert diesen. NPV ist daher präziser für langfristige Projekte.

Erklärung:

NPV (Net Present Value): - Berücksichtigt den Zeitwert des Geldes (Diskontierung) - Verwendet einen Discount Rate (z.B. 10%) - Präzisere Bewertung langfristiger Projekte - Komplexere Berechnung

ROI (Return on Investment): - Einfaches Verhältnis von Gewinn zu Investition - Ignoriert den Zeitwert des Geldes - Einfacher zu verstehen - Schnelle Entscheidungen

Beispiel: - Projekt A: Cashflow €200.000 in Jahr 1 → NPV (10%) = €181.818 - Projekt B: Cashflow €200.000 in Jahr 5 → NPV (10%) = €124.185

Beide Projekte haben denselben ROI von 100%, aber Projekt A ist vorteilhafter, da der Cashflow früher fließt. NPV würde Projekt A bevorzugen.

Frage 14: Vendor Lock-in

Ein Unternehmen plant die Einführung einer Cloud-basierten SaaS-Lösung für das CRM. Was ist Vendor Lock-in und wie kann es vermieden werden?

A) Vendor Lock-in ist das Problem, dass ein Unternehmen von einem Anbieter abhängig wird. Es kann durch Containerization (Docker, Kubernetes), Multi-Cloud-Strategie und Offene Standards vermieden werden.

B) Vendor Lock-in ist das Problem, dass ein Unternehmen zu viele Anbieter hat. Es kann durch Konsolidierung vermieden werden.

C) Vendor Lock-in ist kein Problem bei Cloud-SaaS-Lösungen.

D) Vendor Lock-in kann nur durch vollständige Vermeidung von Cloud-SaaS vermieden werden.

Lösung: Frage 14

A) Vendor Lock-in ist das Problem, dass ein Unternehmen von einem Anbieter abhängig wird. Es kann durch Containerization (Docker, Kubernetes), Multi-Cloud-Strategie und Offene Standards vermieden werden.

Erklärung:

Vendor Lock-in: - Abhängigkeit von einem bestimmten Anbieter - Schwieriger Wechsel zu anderen Anbietern - Hohe Migrationskosten

Vermeidungsstrategien: - Containerization: Docker, Kubernetes für Portabilität - Multi-Cloud-Strategie: Nutzung mehrerer Cloud-Provider - Offene Standards: Verwendung offener Standards (OpenAPI, GraphQL) - Managed Services mit Portabilität: Azure VM, AWS EC2 (einfacher zu migrieren als PaaS-Services) - Export-Features: Regelmäßige Datenexporte

Frage 15: Defense in Depth

Was ist Defense in Depth und warum ist es eine wichtige Sicherheitsstrategie?

A) Defense in Depth ist eine Sicherheitsstrategie mit nur einer Sicherheitsmechanismus. B) Defense in Depth ist eine Schicht-Sicherheitsstrategie, die mehrere, unabhängige Sicherheitsmechanismen kombiniert. Wenn eine Schicht durchbrochen wird, bieten andere Schutz. C) Defense in Depth ist eine Strategie für die Datenbank-Sicherheit. D) Defense in Depth ist nur für große Unternehmen relevant.

Lösung: Frage 15

B) Defense in Depth ist eine Schicht-Sicherheitsstrategie, die mehrere, unabhängige Sicherheitsmechanismen kombiniert. Wenn eine Schicht durchbrochen wird, bieten andere Schutz.

Erklärung:

Defense in Depth: - Mehrere Schichten der Sicherheit - Redundanz: Wenn eine Schicht durchbrochen wird, bieten andere Schutz - Risiko-Reduzierung: Ein einzelner Fehler hat keine katastrophalen Folgen - Anpassungsfähigkeit: Jede Schicht kann unabhängig angepasst werden

Beispiel-Schichten: 1. Perimeter-Schicht: Firewall, DDoS-Schutz 2. Netzwerk-Schicht: Network Segmentation, VPN 3. Anwendungs-Schicht: WAF, Rate Limiting 4. Anwendungs-Logik: Input Validation, Auth 5. Datenschutz-Schicht: Verschlüsselung, Backup

Quiz-Ergebnis

Zählen Sie Ihre korrekten Antworten:

12-15 korrekt: Exzellent! Sie haben ein tiefes Verständnis der strategischen Planung in IT-Projekten.
9-11 korrekt: Gut! Sie haben ein solides Verständnis, aber es gibt noch Bereiche zur Verbesserung.
6-8 korrekt: Akzeptabel, aber es wird empfohlen, die betroffenen Kapitel zu wiederholen.
0-5 korrekt: Bitte wiederholen Sie alle Kapitel dieses Moduls.

Nächste Schritte

Wenn Sie das Quiz abgeschlossen haben, können Sie:

Schwache Bereiche identifizieren: Wiederholen Sie die Kapitel, bei denen Sie Fehler gemacht haben.
Praxisanwendung: Wenden Sie das Wissen in einem echten Projekt an.
Zertifizierung: Bereiten Sie sich auf eine Zertifizierung (z.B. PMBOK, PRINCE2) vor.
Weiterbildung: Lesen Sie weiterführende Literatur zu strategischer Planung.