Knowledge Check - Infrastructure as Code
Test your understanding of the key concepts from Module 2. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
A developer runs an ionoscloud_autoscaling_group under sustained load and raises the cores and ram values in the replica configuration, expecting the existing replicas to grow. The running replicas stay the same size. Which statement best explains this behavior?
VM Auto Scaling scales horizontally: it adds and removes whole server replicas rather than resizing them. Changes to the replica configuration take effect on newly created replicas, so replicas that are already running keep their original sizing. To handle more load, let the group scale out by adding replicas, or replace existing replicas so the new sizing applies.
TaskBoard's application servers sit in a private LAN with no public IP allocated. They need to reach the internet to install package updates and call external APIs, but must not be reachable from the internet. Which Terraform resource provides this outbound-only connectivity?
A NAT gateway provides outbound-only internet connectivity, letting private servers initiate connections for updates and external calls while remaining unreachable from the internet. Allocating an ionoscloud_ipblock to each server would give them public ingress, defeating the isolation requirement, and a load balancer handles inbound traffic, not private egress.
A developer provisions a Managed Kubernetes node pool and an ionoscloud_application_loadbalancer, then writes ionoscloud_firewall (NSG) rules and expects them to protect both the worker nodes and the ALB. The rules appear to take effect on standalone server NICs but not on the MKS nodes or the ALB. Why?
NSGs attach at the VM or NIC level, and Managed Kubernetes node pool nodes are excluded from NSG enforcement, as is the Managed ALB. To control traffic to those resources you must use their own mechanisms (for example listener and forwarding rules on the ALB) rather than relying on NSG rules binding to them.
TaskBoard's API server reads from an ionoscloud_s3_bucket for file attachments. The developer configures the application's S3 client with the IONOS API bearer token used for the rest of their Terraform automation, but every request returns an authentication error. What is the correct fix?
IONOS Object Storage exposes an S3-compatible API and is authenticated with an Access Key and Secret Key pair, not the bearer token used for the IONOS Cloud API. The developer should provision an ionoscloud_s3_key and supply the resulting Access Key and Secret Key to the S3 client; bearer tokens and Basic auth do not work against the S3 endpoint.
A developer provisions an ionoscloud_kafka_cluster and outputs the bootstrap servers and client certificate from Terraform so the application can connect. Which two practices correctly handle this output for a production setup?
The IONOS Kafka data plane is authenticated with mTLS, so the application connects using the client certificate rather than a bearer token, Access Key, or Basic auth. Connection strings, credentials, and certificates extracted from Terraform state should be marked sensitive so they are not exposed in plan or apply output, and they must never be committed to a repository.