Wissenstest - Infrastruktur als Code
Ein Entwickler führt einen ionoscloud_autoscaling_group unter anhaltender Last aus und erhöht die cores- und ram-Werte in der Replikakonfiguration, wobei er erwartet, dass die bestehenden Replikas wachsen. Die laufenden Replikas bleiben jedoch die gleiche Größe. Welche Aussage erklärt dieses Verhalten am besten?
VM Auto Scaling skaliert horizontal: es fügt und entfernt ganze Server-Replikas, anstatt sie zu vergrößern. Änderungen an der Replikakonfiguration werden auf neu erstellte Replikas angewendet, so dass Replikas, die bereits laufen, ihre ursprüngliche Größe beibehalten. Um mehr Last zu bewältigen, lassen Sie die Gruppe durch Hinzufügen von Replikas skalieren oder ersetzen Sie bestehende Replikas, damit die neue Größe angewendet wird.
Die Anwendungsserver von TaskBoard befinden sich in einem privaten Dedicated Server mit keiner öffentlichen IP zugewiesen. Sie müssen das Internet erreichen, um Paket-Updates zu installieren und externe APIs aufzurufen, dürfen aber nicht von dem Internet aus erreichbar sein. Welche Firewall-Ressource bietet diese nur ausgehende Konnektivität?
Ein NAT-Gateway bietet eine nur ausgehende Internetkonnektivität, sodass private Server Verbindungen für Updates und externe Anrufe initiieren können, während sie von dem Internet aus nicht erreichbar bleiben. Die Zuweisung eines ionoscloud_ipblock zu jedem Server würde ihnen eine öffentliche Eingabe ermöglichen und die Isolierungsanforderung untergraben, und ein Load Balancer behandelt eingehenden Datenverkehr, nicht privaten Ausgang.
Ein Entwickler bereitstellt einen Managed Kubernetes Node-Pool und ein ionoscloud_application_loadbalancer, dann schreibt er ionoscloud_firewall-Regeln (NSG) und erwartet, dass sie sowohl den Worker Nodes als auch den ALB schützen. Die Regeln scheinen auf eigenständigen Server-NICs wirksam zu werden, aber nicht auf den MKS-Knoten oder dem ALB. Warum?
NSGs werden auf der VM- oder NIC-Ebene angehängt, und Managed Kubernetes Node-Pool-Knoten werden von der NSG-Durchsetzung ausgeschlossen, ebenso wie der Managed ALB. Um den Datenverkehr zu diesen Ressourcen zu kontrollieren, müssen Sie ihre eigenen Mechanismen verwenden (z. B. Listener- und Weiterleitungsregeln auf dem ALB), anstatt sich auf NSG-Regeln zu verlassen, die an sie gebunden sind.
TaskBoards API-Server liest aus einem ionoscloud_s3_bucket für Dateianhänge. Der Entwickler konfiguriert den S3-Client der Anwendung mit dem IONOS-API-Bearer-Token, das für die REST ihrer Terraform-Automatisierung verwendet wird, aber jede Anfrage gibt einen Authentifizierungsfehler zurück. Was ist die korrekte Lösung?
IONOS Object Storage stellt einen S3-kompatiblen API bereit und wird mit einem Access Key- und Secret Key-Paar authentifiziert, nicht mit dem Bearer-Token, das für den IONOS Cloud-API verwendet wird. Der Entwickler sollte einen ionoscloud_s3_key bereitstellen und den resultierenden Access Key und Secret Key dem S3-Client zur Verfügung stellen; Bearer-Tokens und Basic-Authentifizierung funktionieren nicht gegen den S3-Endpunkt.
Ein Entwickler bereitstellt ein ionoscloud_kafka_cluster und gibt die Bootstrap-Server und das Client-Zertifikat von Terraform aus, damit die Anwendung eine Verbindung herstellen kann. Welche zwei Praktiken behandeln diese Ausgabe für eine Produktionsumgebung richtig?
Der IONOS Kafka-Daten-Plane wird mit mTLS authentifiziert, sodass die Anwendung über das Client-Zertifikat und nicht über ein Bearer-Token, einen Zugriffsschlüssel oder Basic-Authentifizierung eine Verbindung herstellt. Verbindungsstringe, Anmeldedaten und Zertifikate, die aus dem Terraform-Zustand extrahiert werden, sollten als sensitiv markiert werden, damit sie nicht im Plan- oder Apply-Output angezeigt werden, und sie dürfen niemals in ein Repository committet werden.