Knowledge Check - Service Integration
Test your understanding of the key concepts from Module 4. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
A developer is wiring the TaskBoard API to its IONOS PostgreSQL cluster. They build the connection string from the Terraform output and explicitly set sslmode=disable because the application runs inside the same VDC. Connections still negotiate TLS regardless of this setting. What explains this behavior?
IONOS PostgreSQL uses an SSL mode of prefer that the client cannot turn off, so encryption in transit is enforced regardless of an application's sslmode=disable request. The driver and Terraform output distractors are wrong because the behavior is a server-side policy of the managed cluster, not a client library or tooling artifact.
The TaskBoard browser frontend needs to let users upload large file attachments directly to IONOS Object Storage without the API server proxying the bytes. Which boto3 approach correctly implements this against IONOS Object Storage?
IONOS Object Storage exposes the AWS S3 API and authenticates with an Access Key and Secret Key, so boto3 must be given an explicit endpoint_url plus those credentials, and presigned URLs let the browser upload without the API touching the bytes. Bearer tokens and IAM roles do not authenticate Object Storage, and NFS is a separate, unrelated storage product.
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 Kafka data plane. What does correct client configuration require?
The IONOS 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 uses IONOS In-Memory DB (Redis) as a session and read cache to scale reads, since the PostgreSQL cluster has no read replicas to offload that traffic. Under sustained load the cache fills to its memory limit. With the default configuration, what happens to new writes once memory is full?
IONOS In-Memory DB defaults to the allkeys-lru eviction policy, so when memory is exhausted it evicts the least recently used keys rather than rejecting writes, which is the expected behavior for a cache-aside read cache. Returning errors on every write is the behavior of a noeviction policy, and the cluster does not auto-scale nodes to absorb cache pressure.
The TaskBoard API calls IONOS AI Model Hub to summarize task descriptions. During a traffic spike, inference requests start returning HTTP 429 responses. Which change correctly handles this in production code?
AI Model Hub returns HTTP 429 Too Many Requests when a rate limit is exceeded, so production code should back off exponentially and reduce volume by caching inference results, for example in In-Memory DB. Tight retry loops worsen throttling, the API authenticates with a Bearer token rather than Basic auth, and the service is an IONOS endpoint, not AWS Bedrock.