AZ-900 — Cloud-Konzepte: 89 Übungsfragen

Step 1: Anforderungen analysieren — Das Start-up braucht schnelle Markteinführung, geringe CAPEX und nutzungsbasierte Abrechnung. Public Cloud-Anbieter bieten genau diese Merkmale: sofort verfügbare Dienste, Pay-as-you-go-Preismodelle und eine breite Palette verwalteter Dienste.

Step 2: Eigenschaften der Modelle gegenüberstellen — Private Cloud und On-Premises erfordern erhebliche Anfangsinvestitionen, längere Beschaffungszeiten und laufende Betriebskosten; Colocation reduziert zwar Verwaltung, bindet aber Kapital und hat oft Mindestvertragslaufzeiten.

Step 3: Entscheidung — Public Cloud ist die passende Wahl, da sie schnelle Skalierung, geringe Vorlaufkosten und hohe Agilität ermöglicht. Trap: Eine häufige Fehlannahme ist, dass Private Cloud grundsätzlich sicherer ist; Sicherheit ist eher eine Frage von Architektur, Prozessen und Compliance-Maßnahmen als vom Grundmodell allein. Warum die falschen Antworten scheitern: Antwort 1 (Private Cloud) — Private Clouds bieten zwar Kontrolle und mögliche Compliance-Vorteile, erfordern aber hohe Investitionen und längere Bereitstellungszeiten, wodurch sie für ein sehr agiles, kapitalarmes Start-up ungeeignet sind. Antwort 3 (On-Premises) — On-Premises bedeutet volle Investition in Hardware und Personal und ist nicht mit dem Pay-as-you-go-Modell kompatibel; Skalierung ist langsamer und teurer. Antwort 4 (Colocation) — Colocation kann Infrastrukturkosten senken, erfordert jedoch oft langfristige Verträge und Management-Aufwand; zudem fehlen die sofortigen Serviceangebote und die Abrechnung nach Nutzung, die in der Public Cloud vorhanden sind. Insgesamt erfüllt nur das Public Cloud-Modell die geforderten Kriterien: schnelle Bereitstellung, geringe Vorabkosten und nutzungsbasierte Abrechnung.

Step 1: Shared Responsibility Modell kurz darstellen Azure übernimmt Verantwortung für die physische Infrastruktur, Netzwerkinfrastruktur im Rechenzentrum, physischen Schutz, Hardware und die Basisplattformdienste. Kunden sind verantwortlich für alles, was sie in der Cloud konfigurieren und betreiben, insbesondere bei IaaS- und teilweise bei PaaS-Lösungen.

Step 2: Konkrete Verantwortungen zuordnen Konfigurieren von Network Security Groups (NSGs) und Firewalls auf VM-Ebene: Das ist typischer Kundenteil — sie legen Sicherheitsregeln, NSGs, virtuelle Netzwerke und Zugriffssteuerungen für ihre VMs fest. Patchen des Gastbetriebssystems auf IaaS-VMs: Ebenfalls Kundensache — Azure stellt die physische Plattform und Hypervisor bereit, aber das Gast-OS in einer IaaS-VM muss der Kunde selbst patchen und verwalten.

Step 3: Azure-Seiten der Verantwortung benennen Wartung und physischer Schutz der Azure-Hardware: Azure ist verantwortlich für die Hardware, die Stromversorgung, Kühlung und physische Wartung innerhalb seiner Rechenzentren. Sicherstellen der physischen Sicherheit und des Zutritts zum Rechenzentrum: Auch Aufgabe von Azure; dies umfasst Zutrittskontrolle, Videoüberwachung und Rechenzentrumsbetrieb. Trap: Viele glauben, dass „Cloud“ bedeutet, der Anbieter kümmert sich um alles. Das gilt für einige Aspekte bei PaaS/SaaS, aber bei IaaS bleibt der Kunde für die Konfiguration und Wartung seiner Gastbetriebssysteme und Anwendungen verantwortlich. Why each wrong answer fails: Konfigurieren von Network Security Groups und Firewalls auf VM-Ebene: Richtig — Kunden konfigurieren Netzwerk- und VM-Sicherheitsrichtlinien. Wartung und physischer Schutz der Azure-Hardware in den Rechenzentren: Falsch — Das ist eine Kernaufgabe des Cloud-Anbieters (Azure). Kunden haben keinen Zugriff auf physische Hardware. Patchen des Gastbetriebssystems (OS) auf IaaS-VMs: Richtig — Bei IaaS stellt Azure Infrastruktur bereit, aber der Kunde ist für das Gast-OS verantwortlich. Sicherstellen der physischen Sicherheit und des Zutritts zum Rechenzentrum: Falsch — Azure gewährleistet physische Sicherung und Zutrittskontrollen in seinen Rechenzentren. Fazit: Optionen 1 und 3 sind typische Kundenverantwortungen im Shared Responsibility Modell, während die physischen Aspekte dem Cloud-Anbieter obliegen.

Step 1: Definition der Modelle — SaaS liefert komplette Anwendungen, die vom Cloud-Anbieter betrieben und gewartet werden. PaaS stellt Laufzeitumgebungen und Plattformfunktionen bereit, während Kunden ihre Anwendungen deployen. IaaS bietet virtuelle Maschinen und Netzwerkressourcen, die der Kunde vollständig verwaltet. On-Premises bedeutet, dass der Kunde alles selbst betreibt.

Step 2: Bewertungsmaßstab — "Minimale Verwaltung" bedeutet, dass der Kunde möglichst wenig Verantwortung für Betriebssysteme, Middleware, Anwendungen, Sicherheitspatches und Infrastrukturwartung hat. SaaS umfasst die komplette Verantwortung beim Anbieter: Software, Laufzeit, Middleware, OS und Infrastruktur werden vom Anbieter verwaltet. PaaS reduziert die Verwaltung gegenüber IaaS, aber der Kunde ist weiterhin für seine Anwendung und deren Konfiguration verantwortlich. IaaS bietet die geringste Abstraktion und somit den höchsten Verwaltungsaufwand. On-Premises erfordert maximalen Aufwand.

Step 3: Anwendung auf die Anforderung — Für schnellste Bereitstellung und minimale operative Last ist SaaS die richtige Wahl, z. B. Office 365 oder Dynamics 365; PaaS wäre zweiter, wenn kundenspezifische Anwendungen nötig sind, aber mehr Verantwortung bleibt. Trap: Häufig wird angenommen, PaaS sei genauso "pflegefrei" wie SaaS; das ist falsch — bei PaaS bleibt die Applikationslogik und deren Betrieb in der Verantwortung des Kunden. Warum jede falsche Antwort scheitert: SaaS (richtig) — Anbieter managen Anwendung, Plattform und Infrastruktur, Kunde nutzt Dienst ohne OS-/Middleware-Verwaltung. PaaS — reduziert Verantwortung, erfordert aber immer noch Management der Anwendung, Konfiguration und teils der Skalierungslogik. IaaS — erfordert volle Kontrolle über VMs, OS-Patches, Skalierung und Netzwerke; nicht minimaler Aufwand. On-Premises — Kunde trägt komplette Verantwortung für Hardware, Netzwerke, Energie, Sicherheit und Management; maximaler Verwaltungsaufwand.

Step 1: Definition der Modelle: Public Cloud bietet geteilte multitenante Ressourcen eines Cloud-Anbieters; Private Cloud ist nur für eine Organisation bestimmt und kann on-premises oder in einem dedizierten, gehosteten Rechenzentrum betrieben werden; Hybrid kombiniert beides, um Flexibilität zu erreichen; Community Cloud teilt Ressourcen zwischen einer Gruppe mit gemeinsamen Anforderungen.

Step 2: Begründung, warum Private Cloud die größte Kontrolle bietet: In einer Private Cloud besitzt oder mietet die Organisation die vollständige Kontrolle über Server, Speicher, Netzwerksegmente, Sicherheitsrichtlinien und physische Standorte. Das erlaubt granularen Zugriff auf Hardware- und Firmware-Ebenen, eigene Wartungszyklen, spezialisierte Netzwerk-Topologien und dedizierte Dienste. Das hat direkte Auswirkungen auf Compliance (z. B. strenge Datenhoheitsanforderungen), Latenzoptimierung und spezifische Sicherheitsanforderungen.

Step 3: Vergleich und Auswirkungen auf Betrieb, SLAs und Kosten: Im Public-Cloud-Modell legt der Anbieter die physischen Wartungsfenster und Hardware-Infrastruktur fest; Kunden profitieren von Skaleneffekten und flexibler Bezahlung (Pay-as-you-go), haben aber weniger Kontrolle. Hybrid erlaubt, sensible Workloads on-premises zu halten und weniger kritische Workloads in die Public Cloud zu verschieben — ein guter Kompromiss zwischen Kontrolle und Skalierbarkeit. Community Clouds bieten geteilte Kontrolle nur innerhalb einer begrenzten Gruppe, weniger als eine dedizierte Private Cloud. Trap: Eine häufige Fehlannahme ist, dass „Hybrid = maximale Kontrolle“; tatsächlich bietet Hybrid Flexibilität, aber die Kontrolle über die Cloud-Seite ist immer noch vom Anbieter abhängig. Nur eine echte Private Cloud (physisch dediziert) ermöglicht volle Kontrolle. Warum jede falsche Antwort fehlschlägt: - Option 1 (Public Cloud): Falsch, weil Ressourcen geteilt werden, der Anbieter die physische Infrastruktur verwaltet und Kunden nur auf abstrakte Ressourcen (VMs, Container, Dienste) zugreifen. Kontrolle über Hardware und physische Netzwerkkomponenten ist begrenzt. - Option 3 (Hybrid Cloud): Falsch als 'größte Kontrolle' — Hybrid erhöht Flexibilität, aber die Public-Seite bleibt kontrolliert durch den Anbieter; nur die on-premises Komponente bietet volle Kontrolle. - Option 4 (Community Cloud): Falsch, da Infrastruktur mit anderen Organisationen geteilt wird; dies schränkt dedizierte Kontrolle und spezielle Hardware-Optimierungen ein. Community Clouds können Governance-Vorteile bieten, aber nicht die vollständig dedizierte Kontrolle einer Private Cloud. Operative Auswirkungen: Die Wahl beeinflusst Kostenmodelle (CapEx vs OpEx), SLA-Verpflichtungen (Anbieter-SLAs vs eigene SLAs) und die Komplexität von Management, Backup und Disaster Recovery. Unternehmen mit hohen Compliance-Anforderungen wählen oft Private Clouds trotz höherer Kosten.

Step 1: Bedarfsanalyse — Das Szenario verlangt zwei Dinge: (a) lokale Speicherung sensibler Finanzdaten wegen regulatorischer Anforderungen und (b) Nutzung von Cloud-Ressourcen für Entwicklung und Skalierung. Diese Anforderungen sprechen dafür, einen Teil der Workloads on-premises zu betreiben und andere in der Public Cloud laufen zu lassen.

Step 2: Abwägung der Topologien — Eine Public Cloud würde sämtliche Ressourcen außerhalb der eigenen Infrastruktur hosten; das verletzt die Vorgabe zur lokalen Speicherung. Eine Private Cloud erfüllt die lokale Kontrolle, bietet aber nicht notwendigerweise die elastische Skalierbarkeit und einfache globale Verfügbarkeit wie eine Public Cloud. Edge Computing bringt Datenverarbeitung näher an Endgeräte, löst aber nicht das Bedürfnis nach elastischer Cloud-Infrastruktur für Entwickler und ist primär für Latenz-reduzierende Szenarien gedacht.

Step 3: Schlussfolgerung — Die Hybrid Cloud kombiniert lokale Kontrolle (z. B. für sensible Daten) mit der Skalierbarkeit und Agilität der Public Cloud für Entwicklungsworkloads, CI/CD-Pipelines, Testumgebungen und burstable Ressourcen. Trap: Eine übliche Fehlannahme ist, dass Private Cloud automatisch alle Bedürfnisse abdeckt; viele Unternehmen unterschätzen den Aufwand und die Kosten, um Private Clouds so elastisch und global verfügbar zu betreiben wie Public Clouds. Warum jede falsche Antwort scheitert: Public Cloud — verletzt die Anforderung, sensible Finanzdaten lokal zu speichern und könnte regulatorische Vorgaben missachten. Private Cloud — bietet zwar Kontrolle, liefert aber nicht die einfache Skalierbarkeit und den globalen Zugriff, den entfernte Entwicklerteams benötigen, ohne erheblichen Investitionsaufwand. Edge Computing — ist auf niedrige Latenz und lokale Verarbeitung von Telemetrie/Datenströmen ausgerichtet, nicht primär auf die Kombination von on-premises Datenspeicherung und skalierbarer Entwicklungsinfrastruktur. Hybrid Cloud (richtig) — kombiniert die Stärken beider Welten und ermöglicht Datenlokalisierung parallel zu Cloud-basierten Entwicklungsservices.

Step 1: Anforderungen identifizieren — Das Unternehmen muss Daten aus Compliance-Gründen lokal halten (on-premises) und möchte gleichzeitig bei Lastspitzen zusätzliche Kapazität aus Azure verwenden. Diese Anforderungen weisen auf die Notwendigkeit einer Kombination aus On-Premises- und Public-Cloud-Ressourcen hin.

Step 2: Modelle abgleichen — Eine Public Cloud allein würde erfordern, dass alle Ressourcen in der Cloud liegen; eine Private Cloud allein würde nur lokale oder dedizierte Hardware nutzen. Multi-Cloud bedeutet Nutzung mehrerer Public-Cloud-Anbieter. Hybrid Cloud ist das Modell, das explizit die Integration von On-Premises-Infrastrukturen mit Public-Cloud-Diensten unterstützt, z. B. für Burst-Szenarien.

Step 3: Entscheidung begründen — Hybrid Cloud ermöglicht, sensible Daten lokal zu halten und gleichzeitig elastisch Rechen- oder Speicherressourcen in Azure zu nutzen, wenn Nachfrage ansteigt. Damit erfüllt es beide Anforderungen: Compliance und Skalierbarkeit. Trap: Ein häufiger Fehler ist zu denken, dass 'Public Cloud' ausreichend ist, weil sie leichter skaliert; das ignoriert jedoch die Compliance-Anforderung, die lokale Datenhaltung verlangt. Hybrid Cloud adressiert beides. Warum jede falsche Antwort fehlschlägt: - Public Cloud: Falsch, weil die Aussage explizit verlangt, dass Daten aus Compliance-Gründen lokal gehalten werden; bei einer reinen Public Cloud würden Daten in der Cloud liegen, was die Anforderung verletzt. - Private Cloud: Falsch, weil eine rein private Umgebung zwar Daten lokal halten kann, aber nicht notwendigerweise die nahtlose Möglichkeit bietet, kurzfristig kosteneffiziente zusätzliche Kapazität in Azure zu nutzen. - Multi-Cloud: Falsch, weil Multi-Cloud die Nutzung mehrerer Public-Cloud-Anbieter (z. B. Azure und AWS) beschreibt, aber nicht das zentrale Merkmal der Kombination lokaler (on-premises) Ressourcen mit Public-Cloud-Ressourcen, das hier erforderlich ist. Zusätzliche Hinweise: In Hybrid-Szenarien kommen oft Technologien wie VPN/ExpressRoute, Identity-Federation (z. B. Azure AD), Datenreplikation mit geeigneten Sicherheits- und Compliance-Kontrollen sowie Automatisierungs- und Orchestrierungsmechanismen für Burst-Funktionen zum Einsatz.

Step 1: Ziel klären — Das Unternehmen will den physischen Kauf von Servern vermeiden und bevorzugt nutzungsabhängige Abrechnung. Das impliziert, dass die physische Hardware und deren Kapitalaufwand nicht vom Kunden getragen werden. In Cloudmodellen wie IaaS und PaaS stellt der Cloudanbieter die physische Infrastruktur (Server, Storage, Netzwerk) bereit, sodass der Kunde keine Hardware anschaffen muss.

Step 2: Modelle vergleichen — IaaS (Infrastructure as a Service) stellt virtuelle Maschinen, Speicher und Netzwerke bereit; der Kunde mietet Ressourcen und bezahlt typischerweise nach Verbrauch, wodurch CAPEX für Hardware entfällt. PaaS (Platform as a Service) geht einen Schritt weiter: Neben der Infrastruktur stellt der Anbieter auch Plattformkomponenten (z. B. Laufzeitumgebungen, Middleware) bereit. Auch hier ist keine physische Hardwarebeschaffung nötig und Abrechnung ist in der Regel pay-as-you-go. SaaS (Software as a Service) liefert komplette Anwendungen; obwohl das die Hardware ebenfalls abstrahiert, fokussiert SaaS auf fertige Anwendungen und nicht auf Plattform-/Infrastruktur-Management im Sinne der Fragestellung. On-Premises bedeutet weiterhin eigener Hardwarebesitz, also genau das, was vermieden werden soll.

Step 3: Schlussfolgerung — Die besten Antworten sind IaaS und PaaS, weil beide explizit das physische Serverbesitzen eliminieren und häufig nutzungsabhängige Abrechnung bieten. SaaS eliminiert auch Besitz von Hardware, aber in der Praxis wird bei Entscheidung für Cloudmigration oft zwischen IaaS und PaaS verglichen, wenn es um den Grad der Kontrolle über Anwendungen und Plattformen geht. On-Premises ist kontraintuitiv zur Zielsetzung. Trap: Eine häufige Fehlannahme ist, dass nur SaaS nutzungsabhängig abgerechnet wird oder dass SaaS automatisch die einzige Möglichkeit ist, keinen Hardwarebesitz zu haben. Tatsächlich bieten IaaS und PaaS ebenso pay-as-you-go-Modelle, wobei sich der Grad der Kundenverantwortung unterscheidet. Warum jede falsche Antwort scheitert: - SaaS (Option 3): SaaS-Anwendungen sind zwar auch cloudbasiert und eliminieren physischen Hardwarekauf, aber die Fragestellung zielt auf Modelle, die Infrastruktur- und Plattformalternativen beim Aufbau eigener Lösungen betreffen. Außerdem kann SaaS nicht immer die Flexibilität bieten, die ein Unternehmen benötigt, wenn es eigene Anwendungen oder spezifische Plattformanforderungen hat. In vielen Migrationsentscheidungen werden IaaS und PaaS als Optionen betrachtet, wenn die Kontrolle über Anwendungen oder Plattformen erhalten bleiben soll. Daher ist SaaS hier nicht die beste Wahl im Kontext der Fragestellung. - On-Premises / eigene Rechenzentren (Option 4): Diese Option verlangt weiterhin den Kauf und die Wartung physischer Server, was genau das ist, was das Unternehmen vermeiden möchte. Daher ist diese Antwort falsch. Zusammenfassung: IaaS und PaaS eliminieren den Hardwarekauf (CAPEX) und bieten in der Regel nutzungsabhängige Abrechnung (OPEX), weshalb beide Antworten korrekt sind; SaaS ist zwar cloudbasiert, aber im Kontext der Fragestellung nicht die passendste Auswahl, On-Premises steht im Widerspruch zum Ziel.

Step 1: Anforderungsanalyse des Szenarios. Die Anwendung hat starke Lastspitzen, die kurzfristig zusätzliche Kapazität erfordern, aber in normalen Zeiten möchten Sie Kosten minimieren. Dies verlangt ein Modell mit schneller Skalierbarkeit und Abrechnung nach Verbrauch.

Step 2: Gegenüberstellung der Optionen. Pay-as-you-go erlaubt sofortiges Hoch- und Herunterskalieren und Abrechnung nur für tatsächlich genutzte Ressourcen — ideal für spitzenlastige Workloads. Physische Server im eigenen Rechenzentrum sind kapitalintensiv (CAPEX) und nicht kurzfristig elastisch. Reserved Instances verringern Kosten für vorhersehbare, langfristig benötigte Kapazität, sind aber weniger flexibel bei plötzlichen, großen Lastspitzen. On-Premises-Lizenzen binden Kapital und bieten keine elastische Skalierung in kurzer Zeit.

Step 3: Entscheidung und Begründung. Pay-as-you-go (verbrauchsbasierte Abrechnung) ist die passendste Wahl, weil Sie nur für die tatsächlich genutzten Ressourcen zahlen und die Cloud-Dienste schnell skaliert werden können — etwa durch Autoscaling-Gruppen oder serverlose Architekturen. Trap: Ein häufiger Fehler ist zu glauben, dass Reserved Instances immer günstiger seien. Sie sparen zwar Kosten bei vorhersehbarer, konstanter Auslastung, aber bei stark schwankender Nutzung kann Pay-as-you-go trotz höherer Stundenpreise günstiger sein, weil keine Kapazitäten ungenutzt vorgehalten werden müssen. Why each wrong answer fails: - Kauf von physischen Servern und Hosting im eigenen Rechenzentrum: Das ist CAPEX, benötigt Vorlaufzeit, verursacht feste Kosten und bietet keine kurzfristige Elastizität. - Langfristiger Reserved Instance-Vertrag für alle benötigten VMs: Reserved Instances sind kosteneffizient bei stabiler Auslastung, aber sie bieten nicht die Flexibilität für unvorhersehbare Spitzen; zudem sind sie Bindungen, die bei Überkapazität Kosten verursachen können. - Lizenzkauf für eine On-Premises-Software mit jährlichem Wartungsvertrag: Bindet Kapital und erhöht Fixkosten; Skalierung erfordert oft zusätzliche Hardware und Vorlaufzeit. Fazit: Pay-as-you-go kombiniert Kostenkontrolle in ruhigen Zeiten mit der Fähigkeit, kurzfristig Kapazität bereitzustellen — daher die beste Wahl im beschriebenen Szenario.

Step 1: Ziel definieren — Das Team möchte sich auf Code konzentrieren und nicht auf Betriebssystem- oder Laufzeitverwaltung. Das bedeutet, die Verantwortlichkeiten für OS-Management, Patches, Skalierung und Laufzeit sollten größtenteils beim Anbieter liegen.

Step 2: Modelle bewerten — PaaS-Angebote stellen die Plattform inklusive Laufzeit, Middleware und oft auch automatische Skalierung bereit; Entwickler übernehmen hauptsächlich das Deployen und Konfigurieren der Anwendung. Serverless (Funktionen) abstrahiert noch weiter: Hier schreibt das Team nur Funktionen/Code, und der Anbieter verwaltet Ausführung, Skalierung, Infrastruktur und oft Abrechnung nach Ausführungszeit. Beide Modelle minimieren oder eliminieren OS- und Plattformverwaltung durch das Team. Dagegen erfordern IaaS und selbstverwaltete VMs, dass das Team OS-Patching, Konfiguration und eventuell Skalierungsmechanismen selbst betreibt.

Step 3: Anwendung auf Szenario — Für ein Team, das sich nur auf Code konzentrieren will, sind PaaS und Serverless am besten geeignet: PaaS eignet sich, wenn eine ganze Anwendung mit bestimmten Laufzeiten oder Middleware gewünscht ist; Serverless eignet sich für ereignisgetriebene, kleine Funktionen mit hoher Skalierbarkeit und minimalem Verwaltungsaufwand. Trap: Ein häufiger Fehler ist zu denken, dass PaaS und serverlose Dienste identisch sind. Beide minimieren die Verwaltungsaufgaben, aber PaaS bietet oft mehr Kontrolle über die Laufzeitumgebung, während Serverless stärker abstrahiert und primär für aufgabenorientierte Kurzläufe gedacht ist. Warum jede falsche Antwort scheitert: - IaaS (Option 3): IaaS stellt virtuelle Maschinen und grundlegende Infrastruktur bereit, bedeutet aber, dass der Nutzer für Betriebssystem-Updates, Sicherheitspatches und häufig für Middleware-Konfigurationen verantwortlich ist. Deshalb erfüllt IaaS nicht das Ziel, sich ausschließlich auf den Code zu konzentrieren. - Self-managed virtuelle Maschinen in der Cloud (Option 4): Diese Option ist klar ähnlich zu IaaS—der Unterschied ist, dass hier explizit vom selbst verwalteten VM-Betrieb gesprochen wird. Das verlangt volle Verantwortung für Betriebssystempflege, Sicherheit und Skalierung und widerspricht dem Wunsch des Teams, sich nur auf Code zu fokussieren. Zusammenfassung: PaaS und serverlose Funktionen geben Entwicklern die größte Freiheit, sich auf Anwendungscode zu konzentrieren, weil der Cloudanbieter die Betriebssystem- und Laufzeitverantwortung übernimmt; IaaS und selbstverwaltete VMs erfordern dagegen weiterhin OS- und Infrastrukturmanagement durch das Team.

Step 1: Shared Responsibility Modell verstehen. In Cloud-Szenarien unterscheidet man oft die Verantwortungsbereiche: Der Provider ist für die physische Sicherheit, Netzwerkinfrastruktur, Hypervisor- und Host-Ebene sowie physische Datensicherheit verantwortlich. Der Kunde ist für alles verantwortlich, was innerhalb seiner virtuellen Maschinen läuft, inklusive Gast-Betriebssystem, Patches, Anwendungen, Daten und Konfigurationen.

Step 2: Anwendung auf IaaS-VMs. Bei IaaS (z. B. Azure Virtual Machines) liefert der Provider die virtuelle Hardware und die Plattformfunktionen, übernimmt aber nicht das Patchen des Guest-OS — das liegt primär beim Kunden. Es gibt managed services oder automatische Update-Optionen, die der Kunde aktiv konfigurieren muss; sie ändern nicht die Grundverantwortung.

Step 3: Praktische Konsequenzen. Kunden sollten Patch-Management-Prozesse, Automatisierungs-Skripte oder Management-Tools (z. B. Azure Update Management) einsetzen, um Sicherheitslücken zu schließen. Bei PaaS oder SaaS verschiebt sich ein größerer Teil der Verantwortung auf den Provider, aber nicht bei IaaS. Trap: Ein häufiger Fehler ist zu glauben, dass der Cloud-Anbieter alles managt. Das gilt nur für bestimmte Dienste (z. B. SaaS) — nicht generell für IaaS. Why each wrong answer fails: Option 1 ist falsch, weil sie die Verantwortlichkeiten überschreibt; Provider managt physische und Hypervisor-Ebene, nicht jedoch das Gast-OS in IaaS. Option 3 ist unzutreffend formuliert: Während es gemeinsame Verantwortung für Security-Aspekte geben kann (z. B. Netzwerksecurity), patched der Provider nicht automatisch das Gast-OS; es ist nicht so, dass beide dieselbe Aufgabe ausführen. Option 4 ist falsch, weil Patches nicht automatisch durch eine neutrale dritte Partei ohne Konfiguration eingespielt werden — Kunden müssen Patch-Strategien implementieren oder entsprechende Managed-Services konfigurieren. Diese Erklärung berücksichtigt reale Faktoren wie SLAs (die Verfügbarkeit der VM betreffen), regionale Compliance (einige Regionen haben spezielle Vorgaben für Patch-Fenster) und typische betriebliche Tools zur Automatisierung von Patching-Aufgaben.

Step 1: Finanzielle Betrachtung — On-Premises-Betrieb bedeuten oft hohe Anfangsinvestitionen in Hardware, Netzwerke und Rechenzentrumsinfrastruktur (CAPEX). Bei SaaS stellt der Anbieter die gesamte Anwendung und Infrastruktur bereit, sodass das Unternehmen typischerweise keine großen einmaligen Hardwareanschaffungen mehr tätigt.

Step 2: Betriebswirtschaftliche Verschiebung — Durch SaaS verschieben sich die Kosten von CAPEX zu OPEX: Statt Kapitalaufwand fallen fortlaufende Abonnements- oder Nutzungsgebühren an. Diese laufenden Kosten sind leichter skalierbar und können besser der Nutzung angepasst werden. Daraus ergeben sich auch Änderungen in Budgetierung und Cashflow-Management.

Step 3: Operative und Kontrolländerungen — Mit SaaS verliert oder reduziert das Unternehmen direkten Zugriff und Kontrolle über das zugrunde liegende Betriebssystem, die Infrastruktur und oft auch bestimmte Konfigurationsmöglichkeiten. Der Anbieter übernimmt Betrieb, Patching und Infrastrukturmanagement. Ebenso entfällt die Notwendigkeit, eigene physische Server zu betreiben, weil die Anwendung vom Anbieter gehostet wird. Trap: Ein verbreiteter Irrtum ist zu glauben, dass SaaS immer kostengünstiger ist als On-Premises. In einigen Szenarien, besonders bei sehr hoher und konstanter Auslastung, können langfristige On-Premises-Kosten oder reservierte Cloud-Kapazitäten wirtschaftlich vorteilhaft sein. Außerdem glauben manche, dass Umstellung auf SaaS automatisch alle betrieblichen Aufgaben eliminiert — Sicherheitskonfiguration und Datenmanagement bleiben weiterhin wichtig. Warum jede falsche Antwort scheitert: - Reduktion von einmaligen Investitionskosten (CAPEX) für Server und Networking (Option 1): Korrekt — SaaS-Anbieter hosten die Anwendung und die zugrunde liegende Infrastruktur, wodurch die Notwendigkeit für einmalige Hardwareinvestitionen beim Kunden in der Regel entfällt. - Verschiebung der Kosten in laufende Betriebskosten (OPEX) wie Abonnements (Option 2): Korrekt — Bei SaaS zahlen Unternehmen meist wiederkehrende Gebühren (monatlich oder jährlich), wodurch Kostenlaufzeiten in OPEX übergehen. - Volle Kontrolle über das zugrunde liegende Betriebssystem der CRM-Instanz (Option 3): Falsch — SaaS-Nutzer haben normalerweise keinen Zugriff auf das zugrunde liegende Betriebssystem oder die physische Infrastruktur; diese Verantwortung verbleibt beim Anbieter. Kunden haben Konfigurationsmöglichkeiten auf Anwendungsebene, aber keine vollständige Kontrolle über das OS. - Erforderlichkeit, physische Server im eigenen Rechenzentrum zu betreiben (Option 4): Falsch — Der Hauptvorteil von SaaS besteht darin, dass der Anbieter die Ausführung und den Betrieb der Anwendung übernimmt; Kunden müssen keine eigenen physischen Server mehr betreiben. Zusammenfassung: Die Migration einer CRM-Anwendung zu SaaS reduziert die CAPEX-Belastung und verschiebt Ausgaben zu OPEX, beseitigt typischerweise die Notwendigkeit physischer Server und reduziert die Kontrolle über das zugrunde liegende Betriebssystem, weshalb die ersten beiden Antworten korrekt sind.

Step 1: Prinzip des Shared Responsibility Model – Die Verantwortlichkeiten werden zwischen Cloudanbieter und Kunde aufgeteilt. Der Anbieter übernimmt physische Komponenten, Netzwerkinfrastruktur und die zugrundeliegenden Plattformdienste; der Kunde ist für seine Daten, Zugriffsverwaltung und Konfiguration seiner Instanzen verantwortlich.

Step 2: Identifikation kundenseitiger Aufgaben – Bei IaaS betreibt der Kunde die VM inkl. OS: also Updates, Patching, Konfiguration und die Sicherheit der darauf laufenden Anwendungen. Auch Datenklassifizierung, Zugriffskontrolle, Verschlüsselung auf Anwendungsebene und Backup-Strategien gehören typischerweise dem Kunden, weil sie geschäftsspezifisch sind.

Step 3: Abgrenzung zum Provider – Der Anbieter sorgt für physische Sicherheit der Rechenzentren, Netzwerkinfrastruktur, Virtualisierungsschicht und die physische Verfügbarkeit. Kunden können auf Provider-Funktionen (z. B. Azure Managed Disk Encryption) zurückgreifen, bleiben aber verantwortlich für Schlüsselmanagement und Anwendungssicherheit, sofern nicht anders vereinbart. Trap: Ein häufiger Fehler ist anzunehmen, dass „die Cloud“ immer alles sichert — tatsächlich bleibt die Schutzverantwortung für Daten und Anwendungskonfiguration beim Kunden, insbesondere bei IaaS und teilweise PaaS. Why each wrong answer fails: - Physische Sicherheit und Zugangskontrolle der Rechenzentren: Dies ist Aufgabe des Cloudanbieters (z. B. Azure) – physische Zutrittskontrolle, Videoüberwachung, Netzwerkracks etc. gehören zur Infrastrukturverantwortung des Providers. - Wartung der zugrundeliegenden Hypervisor-Software: Die Virtualisierungsschicht ist eine Plattformkomponente, die vom Cloudanbieter verwaltet wird; Kunden haben dafür keine administrative Verantwortung. Zusammenfassung: Kunden müssen OS-Patches für ihre IaaS-VMs und datenbezogene Aktivitäten wie Klassifizierung und Verschlüsselung auf Anwendungsebene durchführen; physische Sicherheit und Hypervisor-Wartung gehören typischerweise zum Verantwortungsbereich des Providers.