Wissensprüfung - Service Integration
Eine Entwicklerin verbindet die TaskBoard-API mit ihrem IONOS CLOUD PostgreSQL-Cluster. Sie erstellt die Verbindungszeichenfolge aus der Terraform-Ausgabe und setzt sslmode=disable explizit, da die Anwendung innerhalb desselben VDC ausgeführt wird. Die Verbindungen verhandeln dennoch TLS, unabhängig von dieser Einstellung. Was erklärt dieses Verhalten?
IONOS CLOUD PostgreSQL verwendet einen SSL-Modus von prefer, den der Client nicht ausschalten kann, sodass die Verschlüsselung während der Übertragung unabhängig von der sslmode=disable-Anforderung der Anwendung durchgesetzt wird. Die Ablenkungsoptionen bezüglich des Treibers und der Terraform-Ausgabe sind falsch, da das Verhalten eine serverseitige Richtlinie des verwalteten Clusters ist und kein Artefakt einer Client-Bibliothek oder eines Tools.
Das Browser-Frontend von TaskBoard muss es Benutzern ermöglichen, große Dateianhänge direkt an IONOS CLOUD Object Storage hochzuladen, ohne dass der API-Server die Bytes weiterleitet. Welcher boto3-Ansatz implementiert dies korrekt für IONOS CLOUD Object Storage?
IONOS CLOUD Object Storage stellt die AWS S3 API bereit und authentifiziert sich mit einem Access Key und einem Secret Key. Daher muss boto3 ein explizites endpoint_url sowie diese Zugangsdaten erhalten. Presigned URLs ermöglichen es dem Browser, Daten hochzuladen, ohne dass die API die Bytes verarbeitet. Bearer Tokens und IAM-Rollen authentifizieren Object Storage nicht, und NFS ist ein separates, nicht zusammenhängendes Speicherprodukt.
<!-- TRANSLATION FAILED [unit-4.5-knowledge-check-question-3]: Translation failed for unit-4.5-knowledge-check-question-3 after 3 attempts: Validation failed for unit-4.5-knowledge-check-question-3: ['Checkbox / answer-key mismatch: checkbox count 4 -> 3'] Segment left in English; needs manual translation. -->
A developer adds a Kafka consumer to the TaskBoard worker so it can react to task-change events. Connecting from application code with only a username and password fails to authenticate against the IONOS CLOUD Kafka data plane. What does correct client configuration require?
The IONOS CLOUD Kafka data plane authenticates clients with mutual TLS, so the consumer must present a client certificate over an encrypted connection. The Bearer token applies only to the management API, plaintext is never accepted, and Access Key and Secret Key credentials belong to Object Storage, not Kafka.
TaskBoard verwendet IONOS CLOUD In-Memory DB (Redis) als Session- und Lese-Cache, um Lesezugriffe zu skalieren, da das PostgreSQL-Cluster keine Lese-Replikaten hat, um diesen Traffic abzufangen. Unter anhaltender Last füllt sich der Cache bis an seine Arbeitsspeicher-Grenze. Bei der Standardkonfiguration: Was passiert mit neuen Schreibvorgängen, wenn der Speicher voll ist?
IONOS CLOUD In-Memory DB verwendet standardmäßig die allkeys-lru-Aussortierstrategie. Wenn der Speicher erschöpft ist, werden daher die am längsten nicht verwendeten Schlüssel entfernt, anstatt Schreibvorgänge abzulehnen. Dies ist das erwartete Verhalten für einen Cache-aside-Lese-Cache. Das Zurückgeben von Fehlern bei jedem Schreibvorgang ist das Verhalten einer noeviction-Strategie, und das Cluster skaliert Knoten nicht automatisch, um Cache-Druck aufzunehmen.
Die TaskBoard API ruft IONOS CLOUD AI Model Hub auf, um Aufgabenbeschreibungen zusammenzufassen. Während eines Traffic-Anstiegs beginnen Inferenzanfragen, HTTP 429-Antworten zurückzugeben. Welche Änderung behandelt dies korrekt in Produktionscode?
AI Model Hub gibt HTTP 429 Too Many Requests zurück, wenn ein Rate-Limit überschritten wird. Produktionscode sollte daher exponentiell zurückfahren und das Volumen durch Zwischenspeichern von Inferenzergebnissen reduzieren, beispielsweise in In-Memory DB. Engmaschige Wiederholungsschleifen verschärfen das Drosseln, die API authentifiziert sich mit einem Bearer-Token und nicht mit Basic Auth, und der Dienst ist ein IONOS CLOUD-Endpunkt, nicht AWS Bedrock.