Networking And Compose practice questions

podman-compose rm --all

Why it fails: 'rm' requires stopped containers and does not clean up networks by default like 'down'.

podman-compose destroy

Why it fails: 'destroy' is not a valid subcommand.

podman-compose stop --purge

Why it fails: '--purge' is not a standard compose flag.

podman compose convert --kubernetes

Why it fails: This is not the correct syntax for compose conversion.

podman-compose export --format kubernetes

Why it fails: This flag combination does not exist.

podman generate kubernetes --compose compose.yaml

Why it fails: podman generate kubernetes works on pods/containers, not directly as a compose flag.

HostConfig.PortBindings.IP

Why it fails: PortBindings contains host port mapping rules, not the container IP.

Config.Network.IP

Why it fails: This path does not exist in standard container inspection JSON.

State.Networking.Address

Why it fails: Incorrect path for container IP address.

requires

Why it fails: 'requires' is not a valid compose keyword.

wait_for

Why it fails: 'wait_for' is not part of the compose specification.

links_to

Why it fails: 'links_to' is incorrect.

--port

Why it fails: --port is not a valid Podman flag.

--expose

Why it fails: --expose registers a port internally but does not publish it to the host.

macvlan

Why it fails: Macvlan is a CNI plugin network type, but the core 3 fundamental built-in modes are bridge, host, none.

overlay

Why it fails: Overlay networking requires external multi-host CNI setups or Kubernetes, not native standalone single-host standard execution without plugins.

--dns-server

Why it fails: DNS server is not a direct flag during network creation.

--vlan-id

Why it fails: --vlan-id is not a standard generic bridge network flag.

Host CPU utilization

Why it fails: Network inspect does not show CPU metrics.

Kernel version

Why it fails: Kernel version is a host attribute, not network metadata.

Container disk usage

Why it fails: Disk usage is unrelated to network inspection.

DaemonSet

Why it fails: DaemonSet manifests are not generated directly by podman generate kubernetes.

StatefulSet

Why it fails: StatefulSet manifests are not generated by this command.

Ingress

Why it fails: Ingress objects are not generated by Podman.

compile

Why it fails: 'compile' is not a compose subcommand.

deploy

Why it fails: 'deploy' is typically associated with swarm or stack deploy in Docker, whereas standard podman-compose uses up/down.

sysctl_env

Why it fails: sysctl_env is not a Podman Compose directive; kernel parameters are set via sysctls, not environment variables. It is tempting because sysctl and environment configuration both appear in container specs, but Compose passes variables through environment, env_file, or the -e flag.

container_env

Why it fails: container_env is not a valid Podman Compose key; no such directive exists in the Compose specification. It is tempting because it sounds like a container-scoped variable mechanism, yet environment variables are supplied via environment, env_file, or command-line -e.

podman kube create --compose

Why it fails: Incorrect. This command syntax does not exist.

podman-compose to-kube

Why it fails: Incorrect. 'to-kube' is not a valid subcommand.

podman-compose export --kubernetes

Why it fails: Incorrect. This is not a valid command.

The container automatically shares the host's physical network card.

Why it fails: Incorrect. That behavior belongs to host network mode, not none.

The container is assigned a private IP address on the default bridge.

Why it fails: Incorrect. No bridge IP is assigned in 'none' mode.

podman run --network mynet:192.168.100.50 -d myimage

Why it fails: Appending the address to the network name is not valid podman syntax; the colon form is not parsed as a static IP assignment. It tempts because it resembles Docker-style network naming, but podman requires the ip= qualifier inside the --network value.

podman network connect --ip 192.168.100.50 mynet container_id

Why it fails: podman network connect attaches an existing container to a network after creation, so it cannot assign the address at run time as the stem requires. It is correct for adding a second network to a running container, not for initial static addressing.

podman run --net-static-ip 192.168.100.50 -d myimage

Why it fails: No --net-static-ip flag exists in podman run, so the command fails immediately. Static addressing is configured through the network option itself, which is why this invented flag tempts administrators expecting a dedicated switch for the address.

podman run --net 127.0.0.1:80:8080 myapp

Why it fails: --net joins a network namespace; it does not publish ports, and the argument is not a valid network name. Publishing requires -p or --publish with hostIP:hostPort:containerPort. --net would be correct when attaching a container to an existing Podman network rather than exposing a port.

podman run -p 80:8080/127.0.0.1 myapp

Why it fails: The mapping is reversed: 80:8080 publishes container port 80 on host port 8080, and /127.0.0.1 is invalid syntax. Correct syntax is -p 127.0.0.1:80:8080. Reversed ordering would be right only if the container listened on 80 and the host should expose 8080.

podman run --publish 8080:80/lo myapp

Why it fails: --publish accepts hostPort:containerPort with an optional host IP; /lo is not valid syntax and no loopback binding occurs. The correct form is -p 127.0.0.1:80:8080. The /lo suffix would never be correct, as interface names are not accepted in port mappings.

--share-net

Why it fails: Podman's --share-net expects a container name or ID to join, not a host-stack shortcut; it cannot reference the host itself. It is tempting because sharing another container's netns is its genuine purpose, which suits sidecar or service-mesh patterns where two containers must share one loopback and port space.

--publish host

Why it fails: --publish host is not valid syntax; --publish maps container ports to host ports and takes port mappings, not a network mode. It is tempting because publishing ports is the usual way to expose a container, correct when you want specific host ports forwarded through NAT rather than full host-stack sharing.

--net bridge

Why it fails: --net bridge attaches the container to Podman's default bridge, giving it a separate netns with NAT and a veth pair — exactly the overhead the stem excludes. It is tempting because bridge is the default mode, correct when containers need isolated addressing and outbound NAT rather than host ports.

--network isolated

Why it fails: Podman has no isolated network mode; isolation from all networking is achieved with none. It is tempting because 'isolated' describes the desired outcome of removing external interfaces, but the runtime recognises only bridge, host, none, container, and private.

--network closed

Why it fails: Podman has no closed network mode; valid modes are bridge, host, none, container, and private. It is tempting because the name suggests a sealed network namespace, which is the concept none actually implements by removing every interface except loopback.

--network disabled

Why it fails: Podman has no disabled network mode; the valid isolation mode is none, which creates only a loopback interface. It is tempting because 'disabled' implies networking is switched off, which matches the intended outcome even though the actual keyword differs.

podman inspect --network appnet

Why it fails: podman inspect --network is not valid syntax; inspect takes a container, image, volume or network name as its argument, and --network is not an inspect flag. It is tempting because inspect is the correct verb for configuration details, but the network object must be passed directly, as in podman network inspect appnet.

podman network show appnet

Why it fails: The show subcommand prints a network's configuration, but Podman's inspect subcommand is what returns the full JSON including subnet, gateway and driver fields. Show is intended for a brief human-readable summary, so it omits the detail required here.

podman network status appnet

Why it fails: podman network status is not a Podman subcommand, so the command errors out; network management uses create, ls, inspect, connect and disconnect. It is tempting because status sounds like a natural way to view details, but only podman network inspect appnet returns subnet, gateway and driver configuration.