Wissensprüfung - Governance, Identität und Kosten
FinCorp möchte seine Nicht-Produktionsumgebung von der Produktionsumgebung trennen, um sicherzustellen, dass jede Umgebung als separate Zeile auf der monatlichen Rechnung erscheint, während sie gleichzeitig eine gemeinsame Governance- und Audit-Domäne beibehält. Der Architekt wird gefragt, ob dafür ein zweiter Vertrag erforderlich ist. Was ist die richtige Empfehlung?
Ein VDC ist das regionale und umgebungsbezogene Segmentierungsprimitiv innerhalb eines Vertrags, und jedes VDC produziert bereits seinen eigenen Abschnitt auf der monatlichen Rechnung. Die alleinige Kostensichtbarkeit rechtfertigt daher nicht einen zweiten Vertrag, der die kommerzielle, Governance- und Audit-Grenze darstellt. Ein neuer Vertrag ist nur für Compliance-Isolation, einen unterschiedlichen Eigentümer oder eine separate Rechtsentität oder einen separaten Audit-Umfang gerechtfertigt.
Ein Architekt bindet den ersten regulierten virtuellen Rechenzentrum (VDC) von FinCorp an eine deutsche Region und merkt später, dass eine andere deutsche Region bevorzugt worden wäre. Was ist die Realität des Änderns?
Die Region eines VDC ist bei der Erstellung festgelegt. Reservierte IPv4-Blöcke sind nur in der Region verwendbar, in der sie reserviert wurden, und Images & Snapshots sind regionsspezifisch mit keiner gemanagten Replikation über Regionen hinweg. Da diese regionsspezifischen Attribute dem VDC nicht folgen können, ist die Region (und der Name) eine einwegige Entscheidung, weshalb die Platzierung bewusst und einmalig getroffen wird.
Ein FinCorp-Prüfer muss Aktivitäten überprüfen, darf aber keine Infrastruktur ändern. Die Plattform hat keine Ablehnungsregel. Wie sollte der Architekt diesen Zugriff gewähren?
Der Zugriff basiert auf Gruppen mit Funktionsrechten und Ressourcengewährungen, die getrennt gehalten werden. Das Lesen ist implizit, wenn eine Ressource gewährt wird, und es gibt keine Ablehnungsregel. Das Prinzip der geringsten Rechte wird daher durch die Gewährung nur dessen erreicht, was die Rolle benötigt: die Funktionalität des Aktivitätsprotokollzugriffs und Leseberechtigungen auf Ressourcen. Eine zu umfassende Gewährung kann nicht mit einer Ausnahme gepatcht werden, da keine Ablehnung existiert. Sie müsste entfernt und neu definiert werden.
FinCorp betreibt einen Unternehmens-Identitätsanbieter und möchte den Zugriff auf IONOS so federieren, dass neue Mitarbeiter bei ihrem ersten Login automatisch erstellt und Gruppen zugewiesen werden. Was muss der Architekt dem Team mitteilen?
Die IONOS-Federation unterstützt SAML 2.0 und OIDC, ihr Umfang ist jedoch heute nur Authentifizierung. Es gibt keine just-in-time-Bereitstellung (der Benutzer muss bereits existieren), und der IdP bestimmt nicht die IONOS-Gruppenmitgliedschaft (die Zugriffszuordnung ist auf der Roadmap, aber noch nicht verfügbar). Die Federation überprüft die Person, das Gruppen- und Rechte-Modell regelt jedoch immer noch, was sie tun dürfen, so dass der Lebenszyklus ein explizites manuelles Runbook bleibt.
FinCorp wird einen konstanten Basisbedarf an dedizierten Rechenkernen für mindestens drei Jahre betreiben, erwartet aber gelegentliche Spitzen über diesem Niveau. Der Architekt dimensioniert einen Sparplan. Welcher Ansatz ist korrekt?
Ein Sparplan ist ein ressourcenbasiertes Engagement mit einem Rabatt von 15% bei 1-Jahr und 40% bei 3-Jahr auf dedizierten Kernen und RAM. Der Bedarf über der verpflichteten Menge wird zum Standard-PAYG-Tarif berechnet (der Überschuss wird nicht abgelehnt), und der Plan kann nach der Aktivierung oder dem Stornieren nicht bearbeitet werden. Die sichere Disziplin besteht darin, nur den Grundbedarf zu verpflichten, von dem man sicher ist, dass er während der Laufzeit betrieben wird, und die variablen Spitzen auf flexible PAYG zu lassen, anstatt optimistische Spitzenausgaben zu verpflichten, die später nicht reduziert werden können.