Courseiva

CCNA Networking And Compose Questions

53 questions · Networking And Compose topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQeasy

How do you disconnect a running container from a custom network named 'mynet'?

A.podman container disconnect mynet mycontainer
B.podman network disconnect mynet mycontainer
C.podman network remove mynet mycontainer
D.podman network detach mynet mycontainer
AnswerB

`podman network disconnect` detaches a running container's network interface from the named network without stopping it, satisfying the stem's requirement to disconnect while the container keeps running. The arguments are ordered network first, then container, matching `mynet` and `mycontainer` exactly as specified.

Why this answer

The `podman network disconnect` command removes a container from a specified network, taking the network name and container name as arguments. This is the exact syntax for detaching a running container from a custom network like 'mynet' without stopping it. It is the counterpart to `podman network connect`.

Exam trap

EX188 often tests whether candidates confuse `podman network remove` (deletes the network) with `podman network disconnect` (detaches a container), or whether they invent a `detach` verb that does not exist.

How to eliminate wrong answers

Option A is wrong because `podman container disconnect` is not a valid subcommand — network operations are grouped under `podman network`, not `podman container`. Option C is wrong because `podman network remove` deletes the entire network (and fails if containers are attached), rather than disconnecting a single container. Option D is wrong because `podman network detach` does not exist; the correct verb is `disconnect`.

Practice this question →
2
Multi-Selectmedium

You are defining a Podman Compose file for a web application stack. You need to ensure that the 'app' service can communicate with the 'cache' service using the hostname 'cache', and that the 'cache' service is assigned a static IP address 10.89.0.10 on the custom network 'backend'. Which TWO configuration elements must be present in the Compose file? (Choose two.)

Select 2 answers
A.A service-level extra_hosts entry for 'app' that maps 'cache' to 10.89.0.10.
B.A top-level networks section that defines 'backend' with an ipam configuration specifying the subnet 10.89.0.0/24.
C.A service-level dns entry for 'cache' that lists 10.89.0.10 as the nameserver.
D.A top-level networks section that defines 'backend' with driver: bridge and no ipam configuration.
E.A service-level networks section for 'cache' that attaches it to 'backend' and includes an ipv4_address: 10.89.0.10 entry.
AnswersB, E

To assign a static IP, the network must have a defined subnet. The ipam configuration with a subnet provides the address range from which the static IP is drawn. Without this, Podman cannot validate or assign a fixed address, and the static IP setting would be rejected or ignored. This element is therefore required for the scenario.

Why this answer

Static IP assignment in Podman Compose requires the target network to have a defined subnet via an ipam configuration, and the service must specify ipv4_address under its networks mapping. Together, these allow Podman to assign the exact address and register the service name for DNS. Other options either misconfigure DNS or do not provide the required subnet for static addressing.

Exam trap

The trap here is thinking that a static IP can be assigned on any user-defined network without first defining its subnet, or that a DNS nameserver entry achieves the same result.

Practice this question →
3
MCQhard

You need to inspect the configuration details, including subnet, gateway, and driver, of a custom Podman network named 'appnet'. Which command should you run?

A.podman inspect --network appnet
B.podman network show appnet
C.podman network status appnet
D.podman network inspect appnet
AnswerD

The podman network inspect command outputs the full JSON configuration of the named network, including subnet, gateway and driver details. Appending the network name 'appnet' targets that specific network, satisfying the requirement to examine its configuration.

Why this answer

'podman network inspect <name>' returns detailed JSON configuration for the specified network, including subnet, gateway, driver, IPAM options, and connected containers. This is the correct command to inspect a custom Podman network's configuration details.

Exam trap

EX188 often tests whether candidates confuse 'podman inspect' (containers/images) with 'podman network inspect' (networks), or invent non-existent subcommands like 'network show' or 'network status'.

How to eliminate wrong answers

Option A is wrong because 'podman inspect --network' is not a valid syntax; 'podman inspect' inspects containers or images, and the '--network' flag is not used that way. Option B is wrong because 'podman network show' is not a Podman subcommand. Option C is wrong because 'podman network status' is not a Podman subcommand; network status is not a valid verb.

Practice this question →
4
MCQhard

An administrator needs to connect an already running container named 'web1' to an existing user-defined network named 'backend-net' without restarting the container. Which command accomplishes this?

A.podman network attach backend-net web1
B.podman network connect backend-net web1
C.podman container modify --network backend-net web1
D.podman network join --container web1 backend-net
AnswerB

The podman network connect subcommand attaches a running container to an existing user-defined network at runtime, requiring no container restart or recreation. It satisfies the constraint of connecting web1 to backend-net while the container keeps running.

Why this answer

The podman network connect command attaches a running container to an existing user-defined network without requiring a restart. Its syntax is 'podman network connect <network> <container>', which matches option B. This is the supported way to add a live container to an additional network, and Podman updates the container's DNS and interfaces dynamically.

Exam trap

EX188 often tests the exact subcommand name — candidates may guess 'attach' or 'join' instead of the correct 'connect', or confuse it with 'podman network create'.

How to eliminate wrong answers

Option A is wrong because 'podman network attach' is not a valid subcommand; the correct verb is connect. Option C is wrong because 'podman container modify' does not exist; container modification is done via 'podman update' for resources, and network changes use network connect/disconnect. Option D is wrong because 'podman network join' is not a valid subcommand, and the syntax shown is incorrect.

Practice this question →
5
MCQeasy

A container needs to be created that shares the host's network stack entirely, bypassing any NAT or virtual interface overhead. Which Podman flag achieves this?

A.--share-net
B.--publish host
C.--network host
D.--net bridge
AnswerC

Using --network host places the container directly in the host's network namespace, so it shares the host stack with no NAT or virtual interface. This satisfies the stem's requirement to bypass that overhead entirely, unlike bridge or slirp4netns modes.

Why this answer

Using --network host disables network isolation and places the container directly on the host's network namespace.

Practice this question →
6
MCQeasy

A developer runs a container with 'podman run -d --name web -p 8080:80 nginx' on a host that already has a service listening on port 8080. The container starts but clients cannot reach the containerized web server on that port. Which command most directly reveals why the port mapping failed?

A.ss -ltnp | grep 8080
B.podman logs web
C.podman port web
D.podman inspect web
AnswerA

'ss -ltnp' shows listening TCP sockets with the owning process, so filtering for port 8080 identifies exactly which host process already holds that port. This directly confirms the conflict that prevented Podman from binding the requested host port, giving the administrator the information needed to stop or move the competing service before retrying the container.

Why this answer

A published port fails to bind when another process already holds the host port. The most direct diagnostic is to list listening sockets and their owning processes, which identifies the conflicting service on port 8080. Container-side tools such as logs, port, or inspect describe the container's configuration or output, not the host socket that is occupying the requested port.

Exam trap

The trap here is reaching for container inspection commands to diagnose a host-side port conflict, when the failure actually occurs at the host socket layer before the container is reachable.

Practice this question →
7
MCQeasy

Which environment file option can be used in a Podman Compose file to automatically load environment variables for service configuration?

A.environment_source
B.variables_file
C.env_file
D.load_env
AnswerC

The env_file directive names a file whose KEY=VALUE lines Podman Compose reads and injects as environment variables into the service container at creation, satisfying the requirement to load configuration automatically rather than declaring each variable inline under environment.

Why this answer

In Podman Compose (and Docker Compose), the env_file key within a service definition specifies one or more files containing environment variables in KEY=VALUE format that are loaded into the container at runtime. This is the standard, documented way to inject environment variables from a file rather than listing them inline under environment:. Podman Compose implements this key for compatibility with the Compose specification.

Exam trap

EX188 often tests confusion between similarly named keys like env_file, environment, and non-existent options such as variables_file or load_env, so candidates must recall the exact Compose specification key.

How to eliminate wrong answers

Option A is wrong because environment_source is not a valid Compose key — it does not exist in the Compose specification or Podman Compose implementation. Option B is wrong because variables_file is not a recognized Compose directive; the correct key is env_file. Option D is wrong because load_env is not a Compose key; environment variables are loaded via env_file or the environment mapping, not load_env.

Practice this question →
8
MCQeasy

Which flag allows you to publish a container port to a random ephemeral port on the host interface?

A.-p random
B.-p 0:8080
C.--port dynamic
D.-P
AnswerD

The uppercase -P flag publishes the container's exposed port to a randomly assigned ephemeral port on the host, whereas lowercase -p requires an explicit host-to-container mapping. This suits scenarios where the specific host port is irrelevant.

Why this answer

The -P (uppercase) flag tells podman to publish all EXPOSED ports from the image to randomly assigned ephemeral ports on the host. This is the documented shorthand for --publish-all, and it satisfies the requirement of mapping to a random host port without specifying a fixed number. Lowercase -p requires explicit port mappings and does not have a 'random' keyword.

Exam trap

EX188 often tests the case-sensitivity of podman flags — candidates confuse -p (explicit publish) with -P (publish all exposed ports to random host ports), and the exam deliberately includes plausible-sounding but nonexistent flags like 'random' or 'dynamic'.

How to eliminate wrong answers

Option A is wrong because '-p random' is not valid syntax; -p expects a port mapping in the form hostPort:containerPort or containerPort. Option B is wrong because '-p 0:8080' would attempt to bind host port 0, which is not a valid user-specified port and does not represent the documented ephemeral-port behavior. Option C is wrong because '--port dynamic' is not a podman flag at all; there is no such option.

Practice this question →
9
MCQhard

You want a Podman Compose service to accept connections from other containers on the same Compose network but not from the host, and you do not want the host to be able to reach the service's port. Which Compose configuration achieves this while keeping the service reachable by name within the network?

A.Add 'internal: true' to the service definition and map the port normally with 'ports:'.
B.Set 'network_mode: none' on the service and rely on the Compose network for name resolution.
C.Use 'expose:' to declare the container port without a 'ports:' mapping, and attach the service to the Compose network.
D.Use 'ports:' with the host IP set to 127.0.0.1, for example '127.0.0.1:5432:5432'.
AnswerC

'expose' documents and opens the container port for the Compose network without publishing it to the host, so sibling containers can reach the service by its name and port while the host has no listener for it. Attaching the service to the shared network provides the DNS name resolution. This matches the requirement of internal-only reachability without host exposure.

Why this answer

Declaring the container port with 'expose' while attaching the service to the Compose network lets other containers on that network reach the service by name, because no host-side listener is created. Publishing the port, even on loopback, would still make it reachable from the host, and disabling networking entirely would break intra-network connectivity. The internal-only requirement is met by exposing rather than publishing.

Exam trap

The trap here is treating 'expose' as equivalent to 'ports', when 'expose' only opens the port inside the container network and creates no host listener at all.

Practice this question →
10
MCQmedium

You wish to connect an already running container to an existing custom Podman network named 'mynet'. Which command should you use?

A.podman network attach mynet mycontainer
B.podman container network-add mynet mycontainer
C.podman network connect mynet mycontainer
D.podman network join mynet mycontainer
AnswerC

The podman network connect subcommand attaches an already running container to an existing network, taking the network name then the container. This satisfies the requirement to join 'mynet' without recreating the container, unlike podman run --network, which only applies at creation.

Why this answer

'podman network connect' attaches a running or stopped container to a specified network.

Practice this question →
11
Multi-Selecthard

When working with Podman Compose files, which TWO options are valid keys that can be specified under a service definition for port and networking configuration? (Choose two)

Select 2 answers
A.firewall
B.networks
C.nat_mapping
D.ports
E.ip_address
AnswersB, D

Under a service definition, `networks` is a valid key that attaches the container to one or more named networks declared in the top-level `networks` section, satisfying the networking configuration requirement. It accepts a list or mapping, letting you set per-network aliases and static IPs, unlike `network_mode`, which joins a single existing namespace.

Why this answer

Option B (networks) is correct because in a Compose service definition, the networks key attaches the service's containers to one or more named networks declared in the top-level networks section, controlling inter-service connectivity and DNS resolution. Option D (ports) is correct because the ports key publishes container ports to the host using mappings such as "8080:80", which is the standard Compose mechanism for exposing service ports. Option A (firewall) is not a valid Compose service key; firewall rules are handled by the host or container runtime, not by Compose file syntax.

Option C (nat_mapping) is not a Compose key; NAT behavior is implicit in port publishing rather than configured via a nat_mapping field. Option E (ip_address) is not a valid service-level key in Compose files; static IPs are set under a network's ipv4_address within the service's networks configuration, not as a top-level service key.

Exam trap

EX188 often tests which keys are actually part of the Compose specification versus plausible-sounding invented keys like firewall, nat_mapping, or ip_address, and candidates who guess based on Docker run flags pick the wrong ones.

Practice this question →
12
MCQeasy

A containerized web service must be accessible from the host system on TCP port 8080, while the application inside the container listens on port 80. Which flag correctly configures this port mapping?

A.--expose 8080:80
B.-p 80:8080
C.-p 8080:80
D.--port-map 8080=80
AnswerC

Docker's -p flag maps host port to container port as host:container. Since the host must expose 8080 and the application listens on 80 inside the container, -p 8080:80 satisfies both constraints, routing host traffic on 8080 to container port 80.

Why this answer

The `-p` (or `--publish`) flag maps a host port to a container port using the syntax `-p HOST_PORT:CONTAINER_PORT`. Since the host must expose TCP 8080 and the application inside the container listens on port 80, the correct mapping is `-p 8080:80`. This forwards traffic arriving on host port 8080 to container port 80.

Exam trap

EX188 often tests the direction of the port mapping syntax; candidates frequently reverse `HOST:CONTAINER` and pick `-p 80:8080`, forgetting that the left side is always the host port.

How to eliminate wrong answers

Option A is wrong because `--expose` only documents a port for inter-container communication and does not publish it to the host; also, `--expose` takes a single port, not a `host:container` pair. Option B is wrong because `-p 80:8080` reverses the mapping, publishing container port 8080 to host port 80, which does not match the requirement. Option D is wrong because `--port-map` is not a valid Podman/Docker flag; the correct flag is `-p` or `--publish`.

Practice this question →
13
MCQhard

An administrator creates a custom CNI network using 'podman network create mynet' and wants to assign a static IP address to a container upon creation. Which option achieves this?

A.podman run --network mynet:192.168.100.50 -d myimage
B.podman run --network mynet --ip 192.168.100.50 -d myimage
C.podman network connect --ip 192.168.100.50 mynet container_id
D.podman run --net-static-ip 192.168.100.50 -d myimage
AnswerB

Passing '--ip 192.168.100.50' alongside '--network mynet' assigns the static address within that custom CNI network at container creation. Podman only honours the static IP when the named network is specified, satisfying the requirement to fix the address during 'podman run'.

Why this answer

The `--ip` flag combined with `--network mynet` is the correct way to assign a static IP to a container on a custom CNI network in Podman. The syntax `podman run --network mynet --ip 192.168.100.50 -d myimage` attaches the container to the named network and requests the specified IP from the network's IPAM range. The IP must fall within the subnet defined when the network was created.

Exam trap

EX188 often tests whether candidates invent plausible-sounding flags like `--net-static-ip` or misuse the colon syntax in `--network`, instead of using the correct `--ip` flag with a named network.

How to eliminate wrong answers

Option A is wrong because the syntax `--network mynet:192.168.100.50` is not valid Podman syntax — the colon notation is used for aliases or options, not for specifying an IP address. Option C is wrong because `podman network connect --ip` is used to attach an existing container to a network, not to assign a static IP at creation time, and the question specifies assignment upon creation. Option D is wrong because `--net-static-ip` is not a valid Podman flag — no such option exists in the Podman CLI.

Practice this question →
14
MCQeasy

Which command starts services defined in a Podman Compose file in detached mode?

A.podman-compose background
B.podman-compose start --detach
C.podman-compose up -d
D.podman-compose run -d
AnswerC

`podman-compose up -d` creates and starts every service declared in the Compose file, with `-d` detaching the containers so the terminal returns immediately. This directly satisfies the stem's requirement for detached mode, unlike `up` alone, which streams logs and blocks the session.

Why this answer

`podman-compose up -d` is the direct equivalent of `docker-compose up -d`: it creates and starts all services defined in the compose file and runs them in detached (background) mode. The `-d` flag is the standard shorthand for `--detach` across both Docker Compose and podman-compose.

Exam trap

EX188 often tests whether candidates confuse `up -d` (create and start detached) with `start` (start existing containers) or `run` (one-off container) — the verbs are not interchangeable.

How to eliminate wrong answers

Option A is wrong because `podman-compose background` is not a valid subcommand — there is no `background` verb in podman-compose. Option B is wrong because `podman-compose start --detach` is invalid; `start` only starts existing stopped containers and does not accept `--detach` (it is inherently non-attached). Option D is wrong because `podman-compose run -d` runs a one-off command in a new container, not the full set of services defined in the compose file.

Practice this question →
15
MCQeasy

An administrator needs to run a container that shares the host's network namespace directly so it can listen on privileged ports without port forwarding. Which Podman command flag achieves this network mode?

A.--network host
B.--network bridge
C.--publish-all
D.--net=none
AnswerA

`--network host` places the container directly in the host's network namespace, so it binds host interfaces and privileged ports without NAT or `-p` forwarding. This satisfies the stem's requirement to share the host namespace and listen on privileged ports directly, unlike bridge or slirp4netns modes.

Why this answer

The `--network host` flag runs the container in the host's network namespace, meaning it shares the host's IP address and can bind to privileged ports (e.g., port 80) without port forwarding. This is the correct flag for the described requirement.

Exam trap

EX188 often tests the difference between network modes; candidates may think `--publish-all` shares the host network, but it only publishes ports on a bridge network.

How to eliminate wrong answers

Option B is wrong because `--network bridge` connects the container to a bridge network, which provides isolation and requires port publishing to expose ports. Option C is wrong because `--publish-all` publishes all exposed ports to random host ports, but it does not share the host network namespace. Option D is wrong because `--net=none` disables networking entirely, giving the container only a loopback interface.

Practice this question →
16
MCQeasy

Which configuration block in a Podman Compose YAML file is used to define custom isolated networks for the multi-container application?

A.interfaces:
B.bridges:
C.networks:
D.connections:
AnswerC

The top-level networks: block declares custom isolated networks and their drivers, letting services join named networks for inter-container communication. Without it, Compose attaches containers to a single default network, so this block is what defines the isolation the scenario requires.

Why this answer

In a Podman Compose YAML file, the top-level 'networks:' block defines custom isolated networks for the multi-container application. Services then reference these networks via their own 'networks:' key to attach to them.

Exam trap

EX188 often tests the exact YAML key for networks, confusing it with Docker-specific terms like 'bridges' or generic terms like 'interfaces'.

How to eliminate wrong answers

Option A is wrong because 'interfaces:' is not a valid Compose top-level key; network interfaces are configured at the container level, not defined as a Compose block. Option B is wrong because 'bridges:' is not a Compose keyword; while Docker uses bridge drivers, the YAML block is still 'networks:'. Option D is wrong because 'connections:' is not a Compose block; it is not used to define networks in Compose specifications.

Practice this question →
17
Multi-Selecthard

You are troubleshooting a Podman Compose deployment where containers on a user-defined network cannot resolve each other by service name, although they can reach each other by IP address. Which TWO conditions would explain the name resolution failure? (Choose two.)

Select 2 answers
A.Each service publishes its port to the host with 'ports:', which replaces the internal DNS records.
B.The Compose file sets 'dns:' on each service to an external resolver that has no record of the service names.
C.The containers are running with '--network none' but have static /etc/hosts entries for each other.
D.The containers were attached to the default bridge network instead of the Compose-created user-defined network.
E.The aardvark-dns process responsible for answering queries on that network is not running or failed to start.
AnswersD, E

Name resolution by service name is provided by aardvark-dns on user-defined networks. The default bridge network does not provide automatic service-name DNS for containers, so containers placed there can communicate by IP but cannot resolve each other's names. Ensuring the services are attached to the Compose-created network restores name resolution.

Why this answer

Service-name resolution on a user-defined Podman network depends on two things: the containers must be attached to that network, and aardvark-dns must be running to answer queries. If containers sit on the default bridge or the DNS service is down, IP connectivity still works through the bridge while name lookups fail. Fixing the network attachment or the DNS service restores resolution.

Exam trap

The trap here is assuming that IP reachability implies DNS is configured, when on Podman the two are independent and a missing network attachment or a stopped aardvark-dns breaks only name resolution.

Practice this question →
18
MCQmedium

Two containers running on the same custom user-defined bridge network need to communicate with each other. What built-in mechanism allows them to resolve each other by container name?

A.Automatic DNS resolution provided by the CNI/Netavark network backend
B.Static ARP table broadcasting managed by the kernel
C.Multicast DNS (mDNS) running inside every container image by default
D.Automatic editing of the host's /etc/hosts file by the Podman daemon
AnswerA

Netavark's embedded DNS server resolves container names to IP addresses for containers attached to the same user-defined bridge network, so no manual linking or /etc/hosts editing is needed. The default bridge lacks this name resolution, making the custom network the enabling factor.

Why this answer

When containers are attached to the same user-defined bridge network in Podman, the Netavark (or CNI) network backend runs an embedded DNS resolver that registers each container's name and aliases. This allows containers to resolve each other by name without any manual configuration, similar to Docker's user-defined bridge behavior. The default bridge network does not provide this; only custom user-defined networks do.

Exam trap

EX188 often tests the misconception that the default bridge network provides automatic DNS resolution, when in fact only custom user-defined networks do.

How to eliminate wrong answers

Option B is wrong because ARP operates at Layer 2 for MAC-to-IP resolution and does not provide name-to-IP resolution for container hostnames. Option C is wrong because mDNS (Avahi/Bonjour) is not enabled by default inside container images and is not the mechanism Podman uses for inter-container name resolution. Option D is wrong because Podman does not edit the host's /etc/hosts file for container-to-container resolution; that would be a host-level, not container-level, mechanism and is not how Netavark DNS works.

Practice this question →
19
MCQmedium

Two containers running on the same custom user-defined bridge network need to communicate using container names as hostnames. What is required for this to work natively in Podman?

A.You must use the default 'podman' bridge network.
B.You must edit /etc/hosts inside the containers manually.
C.Nothing extra; user-defined bridge networks include built-in DNS resolution.
D.You must manually link containers using the --link flag.
AnswerC

Podman's user-defined bridge networks run an embedded DNS server, so containers on the same network resolve each other by container name automatically. No manual /etc/hosts entries or links are needed, satisfying the native hostname resolution requirement.

Why this answer

User-defined bridge networks in Podman (and Docker) include an embedded DNS resolver, typically at 127.0.0.11 inside each container, that resolves container names and network aliases to their current IP addresses. Because both containers are attached to the same custom network, Podman's DNS plugin (dnsname/aardvark-dns) automatically registers each container's name, so no manual /etc/hosts editing or --link is needed. This is a core advantage of user-defined networks over the default bridge, which lacks automatic name resolution.

Exam trap

EX188 often tests the misconception that container name resolution requires --link or manual /etc/hosts edits, when in fact user-defined networks provide built-in DNS automatically.

How to eliminate wrong answers

Option A is wrong because the default 'podman' bridge network does not provide automatic DNS-based name resolution between containers — only user-defined networks do. Option B is wrong because manually editing /etc/hosts is unnecessary and fragile; Podman's built-in DNS handles name resolution dynamically. Option D is wrong because --link is a legacy Docker feature that is deprecated and not required on user-defined networks, which already provide name-based connectivity.

Practice this question →
20
MCQmedium

A team maintains a Podman Compose file where the application service must start only after the database service is healthy, not merely after its container is created. Which Compose construct expresses that health-based startup ordering?

A.depends_on with the long syntax including 'condition: service_healthy' alongside a healthcheck on the database service.
B.A restart policy of 'on-failure' on the application service so it retries until the database is ready.
C.depends_on with the short list syntax, for example 'depends_on: [db]'.
D.An 'extends' entry that inherits the database service's healthcheck into the application service.
AnswerA

The long form of 'depends_on' supports a 'condition' key, and 'service_healthy' waits until the dependency's healthcheck reports healthy before starting the dependent service. Pairing it with a healthcheck on the database service gives the application a real readiness gate rather than starting as soon as the database container is created.

Why this answer

Health-based startup ordering is expressed with the long form of 'depends_on' using a condition of service_healthy, combined with a healthcheck on the dependency. The short form only orders creation, restart policies react to failures, and 'extends' merges configuration. Only the conditional depends_on gives a true readiness gate before the dependent service starts.

Exam trap

The trap here is assuming that any 'depends_on' entry waits for the dependency to be healthy, when the short syntax only orders container creation and never checks health.

Practice this question →
21
MCQhard

When utilizing Podman Compose, how are service dependencies and container startup orders typically managed within the YAML structure?

A.By ordering the service keys alphabetically in the YAML file
B.Using the 'links' parameter exclusively
C.Through the 'startup_order' directive
D.Using the 'depends_on' configuration key under the service definition
AnswerD

The depends_on key declares which services must start before a given service, so Podman Compose orders container startup accordingly. It satisfies the stem's requirement for managing service dependencies directly within the YAML service definition, rather than relying on external orchestration or manual sequencing.

Why this answer

Podman Compose, like Docker Compose, uses the 'depends_on' key under a service definition to express startup dependencies. This ensures that when a service is started, its dependencies are started first, controlling the order in which containers are launched. The 'depends_on' key does not wait for the dependent service to be 'ready' (e.g., healthy), only that it has been started, unless combined with health checks and conditions in some versions.

Exam trap

EX188 often tests the misconception that 'links' or alphabetical ordering controls startup order, when in fact 'depends_on' is the correct key for dependency management.

How to eliminate wrong answers

Option A is wrong because ordering service keys alphabetically has no effect on startup order; YAML mapping order is not semantically meaningful for dependency resolution. Option B is wrong because the 'links' parameter is used for network aliasing and enabling service discovery, not for controlling startup order; it does not guarantee dependency order. Option C is wrong because there is no 'startup_order' directive in Podman Compose or Docker Compose; startup order is managed via 'depends_on' (and optionally health checks).

Practice this question →
22
MCQhard

You are using Podman Compose to define a multi-service application. The 'web' service must resolve the hostname 'db' to the 'db' service container's IP address, and the 'db' service must not be reachable from outside the Compose network. Which Compose configuration achieves this?

A.Use network_mode: host for both services and rely on the host's DNS resolution.
B.Define both services in the same Compose file without any networks section, and publish the db service port to the host.
C.Define a custom network, attach both services to it, and do not publish any ports for the db service.
D.Attach the web service to a custom network and the db service to the default network, then use links to connect them.
AnswerC

A user-defined network provides automatic DNS resolution between containers on that network, so 'web' can resolve 'db'. By not publishing ports for the db service, it remains accessible only to containers on the same network, satisfying the isolation requirement. This is the standard Podman Compose pattern for secure inter-service communication.

Why this answer

A user-defined Compose network enables automatic DNS resolution among attached services, so the web service can reach the db service by its service name. Keeping the db service off any published host port ensures it is not externally reachable. Using host networking or split networks breaks name resolution or isolation, and publishing the db port defeats the security goal.

Exam trap

The trap here is believing that service name resolution works across different networks or with host networking, when it requires a shared user-defined network.

Practice this question →
23
MCQmedium

An administrator needs to inspect the configuration details, including subnet and gateway, of an existing custom network named 'my-net'. Which command should be executed?

A.podman network show my-net
B.podman network details my-net
C.podman network inspect my-net
D.podman inspect network my-net
AnswerC

The inspect subcommand reads the stored network configuration and prints JSON detailing subnet, gateway and driver settings for my-net. Unlike listing commands, which show only names, inspect exposes the full definition, satisfying the requirement to view subnet and gateway details.

Why this answer

The correct command is 'podman network inspect my-net'. The 'inspect' subcommand returns detailed JSON output about the network, including subnet, gateway, and connected containers. It is the standard way to view network configuration.

Exam trap

EX188 often tests the exact subcommand syntax, confusing 'inspect' with non-existent verbs like 'show' or 'details', or misplacing the object type.

How to eliminate wrong answers

Option A is wrong because 'podman network show' is not a valid subcommand; 'show' does not exist for network operations. Option B is wrong because 'podman network details' is not a valid subcommand; the correct verb is 'inspect'. Option D is wrong because 'podman inspect network my-net' uses incorrect syntax — 'podman inspect' takes an object name or ID, not a type keyword like 'network'; the correct form is 'podman network inspect'.

Practice this question →
24
MCQeasy

How do you check the logs of all services managed by a Podman Compose file?

A.podman-compose monitor
B.podman-compose logs
C.podman-compose output
D.podman logs --compose
AnswerB

The logs subcommand aggregates stdout and stderr from every container defined in the Compose file, streaming them with service-name prefixes. Running it against the compose file satisfies the requirement to inspect all managed services at once, whereas podman logs only targets a single named container.

Why this answer

'podman-compose logs' displays log output from all services defined in the compose file.

Practice this question →
25
MCQhard

When generating a Kubernetes Pod YAML from a Podman container using 'podman generate kubernetes', how are published ports mapped into the resulting Kubernetes manifest?

A.They are translated into container port definitions within the containers spec array.
B.They are converted into host-level iptables rules embedded in annotations.
C.They are ignored entirely and must be added manually.
D.They cause the generation command to fail with a port conflict error.
AnswerA

Podman's published ports become containerPort entries inside the containers spec array, since Kubernetes Services, not the Pod manifest, handle host-level exposure. This satisfies the stem's requirement that published ports map into the generated manifest as container port definitions.

Why this answer

When generating a Kubernetes Pod YAML from a Podman container, published ports are translated into containerPort entries within the containers spec array. This reflects the container's exposed ports in the Kubernetes manifest, allowing the Pod to declare which ports it listens on.

Exam trap

EX188 often tests the mapping of Podman features to Kubernetes YAML; candidates may think ports are ignored or converted to hostPort, but they become containerPort entries.

How to eliminate wrong answers

Option B is wrong because Kubernetes manifests do not embed iptables rules; networking is handled by the CNI plugin and kube-proxy, not by annotations. Option C is wrong because published ports are not ignored; they are included as containerPort definitions. Option D is wrong because port conflicts do not cause the generation command to fail; the command simply translates the configuration.

Practice this question →
26
MCQmedium

You want to create a Podman network with a specific subnet and gateway. Which command correctly specifies these parameters?

A.podman network create --subnet 192.168.200.0/24 --gateway 192.168.200.1 customnet
B.podman network create --ip-range 192.168.200.0/24 customnet
C.podman network new --subnet=192.168.200.0/24 customnet
D.podman network create customnet --network 192.168.200.0/24
AnswerA

The `--subnet` and `--gateway` flags on `podman network create` define the CNI bridge network's address range and default router directly, satisfying the stem's requirement for a specific subnet and gateway. Both parameters are applied at creation time, so the resulting `customnet` network uses 192.168.200.0/24 with 192.168.200.1 as its gateway.

Why this answer

The `podman network create` command accepts `--subnet` to define the CIDR block and `--gateway` to set the gateway IP for the new network, with the network name as the positional argument at the end. Option A uses both flags correctly with valid syntax, creating a network named `customnet` on 192.168.200.0/24 with gateway 192.168.200.1. This is the canonical form documented in podman-network-create(1).

Exam trap

EX188 often tests flag-name confusion — candidates pick `--ip-range` thinking it defines the subnet, or invent a `--network` flag on `network create` because they've seen it on `podman run`.

How to eliminate wrong answers

Option B is wrong because `--ip-range` only restricts the pool of addresses Podman allocates to containers within a subnet; it does not define the subnet itself, and no gateway is specified. Option C is wrong because `podman network` has no `new` subcommand — the correct verb is `create`. Option D is wrong because `--network` is not a valid flag for `podman network create`; the network name is a positional argument, not passed via `--network` (which is used on `podman run` to attach a container to a network).

Practice this question →
27
MCQmedium

An operator runs a Podman container and needs to inspect its assigned IP address directly from the container's runtime inspection output. Which command filters the JSON output to show only the IP address?

A.podman show-ip container_name
B.podman inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name
C.podman network ip container_name
D.podman inspect --ip container_name
AnswerB

Podman stores each network's IP under NetworkSettings.Networks, so the Go template must range over that map to reach IPAddress; a bare .NetworkSettings.IPAddress returns nothing. The --format flag applies this template to the inspect JSON, printing only the address.

Why this answer

Podman stores container runtime metadata in a JSON structure accessible via 'podman inspect'. The Go template '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' iterates over the Networks map and prints only the IPAddress field, which is exactly the filtering behavior required. This avoids dumping the full JSON and isolates the assigned IP.

Exam trap

EX188 often tests whether candidates know that Podman inspection filtering requires Go templates via --format, not a dedicated --ip flag or subcommand.

How to eliminate wrong answers

Option A is wrong because 'podman show-ip' is not a valid Podman subcommand. Option C is wrong because 'podman network ip' does not exist; network inspection uses 'podman network inspect'. Option D is wrong because 'podman inspect' has no --ip flag — filtering must be done with --format and a Go template.

Practice this question →
28
MCQmedium

You are running a rootless Podman container that serves a web application on port 8080. You want users on other machines in the 192.168.1.0/24 subnet to reach the service by connecting to the host's IP address on port 8080. The host's firewall allows the traffic. Which command correctly publishes the container port?

A.podman run -d -p 192.168.1.0/24:8080:8080 myapp
B.podman run -d --publish-all myapp
C.podman run -d -p 8080:8080 myapp
D.podman run -d --expose 8080 myapp
AnswerC

Omitting a host IP in the -p flag causes Podman to bind the published port on all host interfaces, including the host's 192.168.1.x address. Other machines on the subnet can therefore reach the service at the host IP on port 8080. This is the correct and simplest syntax for the scenario, and it works in rootless mode because the port is above 1024.

Why this answer

To publish a container port to all host interfaces, the -p flag must be used with the host-port:container-port syntax and no host IP. Podman then binds the host port on every interface, allowing subnet clients to connect via the host's 192.168.1.x address. Using a CIDR as a host IP is invalid, --publish-all assigns random ports, and --expose does not publish anything.

Exam trap

The trap here is assuming that a subnet or CIDR can be specified as the host IP in a port mapping, when only a single IP address or no address is allowed.

Practice this question →
29
MCQmedium

You need to inspect the network traffic of a container by capturing packets on its virtual interface. Where can you find the host-side veth interface name associated with a running container?

A.It is always named 'eth0' on the host system.
B.In the /etc/resolv.conf file inside the container.
C.In the systemd journal logs exclusively.
D.In the container's network inspection output under network interface details.
AnswerD

Running podman network inspect or the equivalent container network inspection command lists the container's network interface details, including the host-side veth pair name. That name is then used with tcpdump on the host to capture the container's traffic.

Why this answer

The host-side veth interface name is found in the container's network inspection output, typically via 'podman inspect <container>' under the 'NetworkSettings' or 'Networks' section, which lists the interface name and its peer. This allows the admin to identify the correct veth to capture packets on.

Exam trap

The trap is assuming the host-side interface shares the container's 'eth0' name — candidates forget that veth pairs have different names on each end, and the host side is randomly generated.

How to eliminate wrong answers

Option A is wrong because the host-side veth is never 'eth0' — 'eth0' is the interface name inside the container's network namespace; on the host, the veth has a generated name like 'veth1234abc'. Option B is wrong because /etc/resolv.conf inside the container only contains DNS resolver configuration, not interface names. Option C is wrong because systemd journal logs do not exclusively or reliably contain the veth interface name — it may appear in some logs, but the authoritative source is the container's network inspection output.

Practice this question →
30
MCQmedium

You want to remove a custom Podman network named 'testnet', but it currently has active containers attached to it. What happens?

A.The network is removed, and the containers lose their network interface silently.
B.The deletion fails until all connected containers are stopped and disconnected.
C.The containers are automatically disconnected and moved to the default bridge network.
D.The containers are automatically terminated and the network is removed.
AnswerB

Podman refuses to remove a network while containers remain attached, returning an error rather than silently detaching them. You must stop and disconnect every container from 'testnet' first, satisfying the stem's active-container constraint. This prevents orphaned containers losing network connectivity mid-operation.

Why this answer

Podman refuses to remove a network that has active containers attached to it; the deletion fails with an error indicating the network is in use. The administrator must first stop and disconnect all containers (or use podman network disconnect) before the network can be removed. This prevents silently breaking container connectivity and orphaned interfaces.

Exam trap

EX188 often tests whether candidates know Podman blocks network removal when containers are attached, rather than assuming automatic migration or silent removal.

How to eliminate wrong answers

Option A is wrong because Podman does not silently remove the network and strip interfaces; it blocks the operation to avoid breaking running containers. Option C is wrong because Podman does not automatically migrate containers to the default bridge; the user must explicitly disconnect or stop them. Option D is wrong because Podman does not terminate containers automatically; that would be destructive and is not the behavior of 'podman network rm'.

Practice this question →
31
Multi-Selecthard

Which TWO files or backend network management utilities are heavily relied upon by Podman for container networking stack configuration on modern Linux distributions? (Choose two.)

Select 2 answers
A.aardvark-dns
B.libnetwork
C.docker-proxy
D.iptables-nft
E.netavark
AnswersA, E

Aardvark-dns is the authoritative DNS server paired with netavark, resolving container names to IP addresses on Podman-defined networks. It supplies the name resolution layer the networking stack needs, satisfying the stem's requirement for a backend utility Podman relies upon on modern Linux distributions.

Why this answer

Option E, netavark, is correct because it is the default OCI container network backend for Podman on modern Linux distributions, responsible for setting up container network interfaces, bridges, and firewall rules. Option A, aardvark-dns, is correct because it is the authoritative DNS server that Podman relies on to provide name resolution between containers on the same network, working alongside netavark. Together, netavark and aardvark-dns replaced the older CNI-based stack as Podman's default networking solution.

Option B, libnetwork, is incorrect because it is Docker's networking library, not Podman's backend. Option C, docker-proxy, is incorrect because it is a Docker component for port forwarding, not used by Podman. Option D, iptables-nft, is incorrect because although Podman may interact with nftables through netavark, iptables-nft itself is not a Podman-specific networking utility relied upon for stack configuration.

Exam trap

EX188 often tests whether candidates confuse Docker's libnetwork/docker-proxy stack with Podman's netavark/aardvark-dns stack, or mistake a generic firewall tool like iptables-nft for a Podman-specific backend.

Practice this question →
32
Multi-Selecteasy

Which THREE commands are valid Podman subcommands for managing container networks? (Choose three)

Select 3 answers
A.podman network ls
B.podman network create
C.podman network restart
D.podman network upgrade
E.podman network inspect
AnswersA, B, E

`podman network ls` lists the networks configured in Podman's CNI or Netavark backend, satisfying the stem's requirement for a valid network-management subcommand. It enumerates existing networks with their names, IDs, drivers and creation timestamps, letting you verify which networks containers can attach to before running `podman network inspect` or `podman network create`.

Why this answer

Option A, 'podman network ls', is correct because it is the standard Podman subcommand that lists all configured container networks (equivalent to 'podman network list'), showing network names, IDs, drivers, and interfaces. Option B, 'podman network create', is correct because it creates a new container network, allowing options such as --driver, --subnet, and --gateway to define CNI or Netavark network configuration. Option E, 'podman network inspect', is correct because it outputs detailed JSON metadata about one or more named networks, including subnets, gateways, and connected containers.

Options C and D are not valid Podman subcommands: 'podman network restart' does not exist (networks are not restarted like services; containers are reconnected instead), and 'podman network upgrade' is not a Podman command, as network stack upgrades are handled through package management or 'podman system migrate' rather than a network subcommand.

Exam trap

EX188 often tests whether candidates confuse Docker-style subcommands with Podman's actual command set, so options like `restart` or `upgrade` are planted because they sound plausible but do not exist under `podman network`.

Practice this question →
33
MCQmedium

You need to configure container DNS servers explicitly when running a container, overriding the host's /etc/resolv.conf settings. Which Podman flag do you use?

A.--resolv-conf custom
B.--nameserver 8.8.8.8
C.--dns-search 8.8.8.8
D.--dns 8.8.8.8
AnswerD

`--dns 8.8.8.8` injects the specified resolver directly into the container's `/etc/resolv.conf`, overriding the host's settings. Podman accepts repeatable `--dns` flags for multiple servers, satisfying the requirement to configure DNS explicitly at container runtime rather than inheriting host configuration.

Why this answer

The '--dns' flag on 'podman run' explicitly sets the DNS server(s) inside the container's /etc/resolv.conf, overriding what would otherwise be inherited from the host. Passing '--dns 8.8.8.8' makes the container use Google's public resolver for name lookups, regardless of the host's resolver configuration.

Exam trap

EX188 often tests the confusion between '--dns' (nameserver IP) and '--dns-search' (domain suffix), luring candidates to pick the search flag for setting a resolver address.

How to eliminate wrong answers

Option A is wrong because '--resolv-conf custom' is not a valid Podman flag; the actual flag is '--dns' (and there is a '--dns-search' and '--dns-option' for related settings), so this option invents a nonexistent syntax. Option B is wrong because '--nameserver' is not a Podman run flag — that is a resolv.conf directive name, not a CLI option. Option C is wrong because '--dns-search' sets the search domain suffix (e.g., example.com), not a nameserver IP; passing an IP to it is a misuse and would not configure DNS servers.

Practice this question →
34
MCQmedium

An operator wants to create a custom user-defined bridge network named 'app-net' with a specific subnet of '192.168.100.0/24' using Podman. Which command is correct?

A.podman bridge create app-net --subnet 192.168.100.0/24
B.podman network create --subnet 192.168.100.0/24 app-net
C.podman create network --ip 192.168.100.0/24 app-net
D.podman network new --subnet=192.168.100.0/24 app-net
AnswerB

The --subnet flag sets the custom CIDR, and the trailing positional argument names the network. Podman's network create syntax requires the subnet before the name, so this command produces the 'app-net' bridge with 192.168.100.0/24 as requested.

Why this answer

'podman network create --subnet 192.168.100.0/24 app-net' is the correct syntax: the '--subnet' flag specifies the CIDR, and the network name follows as the positional argument. This creates a user-defined bridge network with the specified subnet.

Exam trap

EX188 often tests command word order — candidates may pick 'podman create network' or 'podman network new' because they sound plausible, but Podman's grammar is strictly 'podman <resource> <verb>'.

How to eliminate wrong answers

Option A is wrong because 'podman bridge create' is not a valid command — bridge networks are created via 'podman network create' with the default bridge driver, not a separate 'bridge' subcommand. Option C is wrong because 'podman create network' reverses the command structure; 'create' is a container subcommand, and 'network' must come first. Option D is wrong because 'podman network new' is not a valid subcommand — Podman uses 'create', not 'new'.

Practice this question →
35
MCQeasy

How do you list all available Podman networks on your system?

A.podman network ls
B.podman network list
C.podman network status
D.podman network show
AnswerA

`podman network ls` queries Podman's local network backend and prints every configured network, including the default podman network, satisfying the requirement to list all available networks. It reads the same CNI or Netavark configuration used at container start, so the output reflects exactly what `podman run --network` accepts.

Why this answer

'podman network ls' is the correct command to list all Podman networks. The 'ls' subcommand is the standard Podman verb for listing resources, consistent with 'podman volume ls', 'podman image ls', and 'podman container ls'.

Exam trap

The trap is assuming 'list' is a valid long form — Podman consistently uses 'ls' across all resource types, and candidates who guess 'list' or 'show' fall for the distractor.

How to eliminate wrong answers

Option B is wrong because 'podman network list' is not a valid subcommand — Podman uses the abbreviated 'ls' form, not the full word 'list'. Option C is wrong because 'podman network status' does not exist; there is no 'status' verb under 'podman network'. Option D is wrong because 'podman network show' is not a valid subcommand — network details are retrieved with 'podman network inspect', not 'show'.

Practice this question →
36
MCQhard

You need to configure a container port mapping in Podman Compose so that host port 80 forwards to container port 8080. Which YAML syntax is correct under the service definition?

A.publish: - 80->8080
B.ports: - "80:8080"
C.expose: - "80:8080"
D.ports: container: 8080 host: 80
AnswerB

The `ports` list maps host to container as `"host:container"`, so `"80:8080"` forwards host port 80 to container port 8080, satisfying the stem's requirement. Quoting the value prevents YAML parsing it as a sexagesimal integer, which would corrupt the mapping. Podman Compose accepts this short syntax directly under the service definition.

Why this answer

In Podman Compose (and Docker Compose), the ports key under a service takes a list of strings in the form "HOST:CONTAINER" to publish a container port on the host. So "80:8080" maps host port 80 to container port 8080. The quotes are recommended because YAML can misinterpret bare numbers containing colons.

Exam trap

EX188 often tests the confusion between ports: (publishes to host) and expose: (internal only), and candidates who remember Docker's arrow notation or invent a mapping-style syntax pick the wrong option.

How to eliminate wrong answers

Option A is wrong because publish: is not a valid Compose service key, and the 80->8080 arrow syntax is not used by Compose (it resembles Podman's -p 80:8080 but with the wrong separator). Option C is wrong because expose: only documents ports that the container listens on for inter-container communication; it does not publish them to the host and does not accept host:container syntax. Option D is wrong because ports: must be a list of strings, not a mapping with container: and host: keys — that structure is not part of the Compose specification.

Practice this question →
37
MCQmedium

You are deploying a container and want to bind its published port exclusively to the loopback interface (127.0.0.1) on the host to prevent external network access. Which syntax is correct?

A.-p 127.0.0.1:8080:80
B.-p 8080:80@127.0.0.1
C.-p 80:80 --host-ip 127.0.0.1
D.--bind-ip 127.0.0.1 -p 8080:80
AnswerA

Binding to 127.0.0.1 restricts the published port to the host's loopback interface, so only local processes can reach container port 80 via host port 8080. This satisfies the stem's requirement to prevent external network access, unlike `-p 8080:80`, which binds all interfaces.

Why this answer

The -p flag accepts an optional host IP prefix in the form [hostIP:]hostPort:containerPort. Specifying 127.0.0.1:8080:80 binds the published port only to the loopback interface, so only processes on the host itself can reach the container's port 80 via host port 8080. This is the standard Docker/Podman port-publishing syntax and is the only option that places the IP in the correct position.

Exam trap

The trap here is that candidates invent plausible-sounding flags like --host-ip or --bind-ip, or misplace the IP after the port mapping; EX188 often tests whether you know the exact [hostIP:]hostPort:containerPort ordering of the -p argument.

How to eliminate wrong answers

Option B is wrong because '@127.0.0.1' is not valid syntax — the '@' character has no meaning in the -p/--publish argument and would cause Podman to reject the value. Option C is wrong because --host-ip is not a real Podman flag; binding is controlled entirely through the -p argument's host-IP prefix. Option D is wrong because --bind-ip is not a Podman option — the correct mechanism is embedding the IP inside the -p value, not a separate flag.

Practice this question →
38
MCQmedium

You are deploying a three-tier application with Podman Compose. The web service must resolve the database service by the name 'db' on the Compose-created network, and you want the web service to keep that name after container restarts. Which action ensures the 'db' alias is resolvable by the web container on the Compose network?

A.Set 'network_mode: host' on the web service so it uses the host resolver for the 'db' name.
B.Publish the database port with 'ports:' and have the web service connect to 'host.containers.internal'.
C.Create a user-defined network in the Compose file and attach both services to it; Compose registers each service name as a DNS alias on that network.
D.Add a 'links:' entry under the web service that lists 'db' with its container name.
AnswerC

When services are attached to the same user-defined network created by Podman Compose, Podman's embedded DNS (dnsname plugin) registers each service name and its aliases as resolvable names inside that network. The web container can then resolve 'db' by the service name defined in the Compose file, and this resolution persists across container restarts as long as the network remains.

Why this answer

Attaching both services to the same user-defined Compose network is what makes service names resolvable. Podman's embedded DNS registers each service name and any declared aliases on that network, so the web container can reach the database as 'db' without static host entries or host port publishing. This also keeps the traffic on the isolated bridge and survives container recreation.

Exam trap

The trap here is assuming that declaring 'links' or publishing ports is what makes a service name resolvable, when in Podman Compose the service-name DNS comes from attaching containers to the same user-defined network.

Practice this question →
39
MCQhard

You need to completely remove a custom user-defined bridge network named 'test-net' that has no active containers attached to it. Which command performs this action?

A.podman network prune --force
B.podman network rm test-net
C.podman rm network test-net
D.podman network delete test-net
AnswerB

The podman network rm command deletes a named user-defined bridge network, and it succeeds here because no containers remain attached. Removing the network directly is the correct action rather than pruning or disconnecting containers first.

Why this answer

'podman network rm test-net' removes the specified user-defined network. Since the network has no active containers attached, the removal succeeds immediately; if containers were attached, Podman would refuse unless forced. This is the direct, correct command for deleting a named network.

Exam trap

EX188 often tests the confusion between 'podman rm' (removes containers) and 'podman network rm' (removes networks), plus the invented 'delete' verb, to catch candidates who guess at syntax.

How to eliminate wrong answers

Option A is wrong because 'podman network prune' removes all unused networks at once, not a specific named one — it is a bulk cleanup, not targeted removal, and '--force' is not the correct way to name a network. Option C is wrong because 'podman rm network test-net' uses the container-removal command 'podman rm' with an invalid argument; 'podman rm' removes containers, not networks, so this syntax fails. Option D is wrong because 'podman network delete' is not a valid subcommand — the correct verb is 'rm' (remove), not 'delete'.

Practice this question →
40
MCQeasy

Which command removes all unused Podman networks that are not currently connected to any containers?

A.podman network prune
B.podman network clean
C.podman network rm --unused
D.podman prune networks
AnswerA

podman network prune removes all networks not connected to any container, exactly matching the requirement. Other network subcommands list, inspect or create networks but do not delete unused ones, so they fail the stated condition.

Why this answer

'podman network prune' deletes unused networks.

Practice this question →
41
Multi-Selecteasy

When configuring container networking in Podman, which TWO built-in network modes are available by default without creating custom networks? (Choose two)

Select 2 answers
A.bridge
B.host
C.macvlan
D.routed
E.overlay
AnswersA, B

Bridge mode is a default Podman network mode, providing NAT-based connectivity between containers and the host on an isolated virtual network. It satisfies the requirement for a built-in mode available without creating custom networks, alongside slirp4netns/pasta.

Why this answer

Option A (bridge) is correct because Podman ships with a default bridge network (named 'podman') that containers attach to by default, providing NAT-based connectivity and inter-container communication on the host. Option B (host) is correct because Podman supports the host network mode out of the box, where the container shares the host's network namespace and uses the host's IP stack directly. Options C (macvlan), D (routed), and E (overlay) are not default built-in modes: macvlan and overlay typically require creating a custom network with specific drivers, and routed is not a standard Podman network mode available without additional configuration.

Exam trap

EX188 often tests whether candidates confuse default built-in network modes (bridge, host) with driver types that require explicit creation (macvlan, overlay, routed).

Practice this question →
42
MCQeasy

You are troubleshooting a container that should have no network access whatsoever for security isolation. Which networking option should you apply?

A.--network isolated
B.--network bridge
C.--network host
D.--network none
AnswerD

The --network none option attaches the container to no network namespace at all, leaving only a loopback interface. This enforces complete isolation, satisfying the requirement for zero network access, unlike bridge or host modes which still permit connectivity.

Why this answer

`--network none` is the Podman option that places the container in an isolated network namespace containing only the loopback interface, providing complete network isolation. This is exactly what is required when a container must have no network access whatsoever for security reasons. It removes all external interfaces and prevents any inbound or outbound traffic beyond the container itself.

Exam trap

EX188 often tests whether candidates pick a plausible-sounding but nonexistent mode like 'isolated' instead of the actual Podman keyword 'none' for full network isolation.

How to eliminate wrong answers

Option A is wrong because `--network isolated` is not a valid Podman network mode — no such keyword exists in the Podman CLI. Option B is wrong because `--network bridge` attaches the container to the default podman0 bridge with NAT, giving it outbound network access, which violates the isolation requirement. Option C is wrong because `--network host` shares the host's network namespace, giving the container full access to host interfaces — the opposite of isolation.

Practice this question →
43
MCQhard

You have created a Podman pod and want to launch two containers inside this pod so they share the same network namespace. How do you specify this during container creation?

A.podman run --pod mypod -d myimage
B.podman run --share-namespace mypod -d myimage
C.podman pod connect mypod myimage
D.podman run --network pod:mypod -d myimage
AnswerA

The --pod flag attaches the new container to an existing pod, so it joins that pod's shared network namespace and can reach sibling containers over localhost. This directly satisfies the requirement that both containers share one network namespace.

Why this answer

The --pod flag on podman run attaches a new container to an existing pod, and all containers in the same pod share the pod's network namespace (and by default its IPC and UTS namespaces). So podman run --pod mypod -d myimage launches the container inside the pod with shared networking. This is the standard way to add containers to a pod after the pod is created.

Exam trap

EX188 often tests the difference between attaching a container to a pod (--pod) and attaching it to a network (--network), and candidates who invent flags like --share-namespace or --network pod: fall for the distractor.

How to eliminate wrong answers

Option B is wrong because --share-namespace is not a valid podman run flag; namespace sharing is controlled by --pod or by explicit --net/--ipc/--uts flags. Option C is wrong because podman pod connect does not exist — the pod subcommands are create, start, stop, rm, ps, inspect, top, pause, unpause, and exists; there is no connect verb for attaching images. Option D is wrong because --network pod:mypod is not the documented syntax; the correct flag is --pod mypod (or --pod=name), and --network is used for CNI/netavark networks, not pods.

Practice this question →
44
Multi-Selecteasy

Which TWO actions can be performed using the 'podman network' subcommand? (Choose two.)

Select 2 answers
A.start
B.build
C.ls
D.commit
E.rm
AnswersC, E

The podman network ls command lists all configured container networks, showing names, IDs, drivers and scope. This read-only action lets administrators inspect available networks before attaching containers, directly satisfying the subcommand's enumeration capability required by the question.

Why this answer

Option C (ls) is correct because 'podman network ls' lists all the container networks configured on the system, which is a core function of the 'podman network' subcommand. Option E (rm) is correct because 'podman network rm' removes one or more specified networks, another valid operation under the 'podman network' subcommand. The unmarked options do not belong: 'start' (A) is used with containers (e.g., 'podman start'), not networks; 'build' (B) is used to build images (e.g., 'podman build'), not networks; and 'commit' (D) creates an image from a container's changes (e.g., 'podman commit'), which is unrelated to network management.

Exam trap

EX188 often tests the distinction between subcommands for different Podman objects (containers, images, networks, volumes), so candidates must know which actions apply to which object type; confusing 'podman network' with 'podman container' or 'podman image' leads to selecting invalid options like 'start' or 'commit'.

Practice this question →
45
MCQhard

You need to troubleshoot name resolution between containers on a custom network. Which backend service does Podman utilize by default for container DNS resolution in modern rootless setups?

A.nscd
B.aardvark-dns
C.dnsmasq
D.bind9
AnswerB

Aardvark-dns is Podman's default authoritative DNS server for custom container networks, resolving container names to their IP addresses. It runs per-network alongside Netavark, Podman's default network backend, and supports rootless operation without requiring root privileges. This satisfies the stem's requirement for the default DNS backend in modern rootless setups.

Why this answer

In modern rootless Podman setups, container name resolution on user-defined networks is handled by aardvark-dns, a lightweight authoritative DNS server that Podman launches per network. It reads container name/IP mappings from the network's configuration and answers A/AAAA queries from containers, enabling name-based communication without editing /etc/hosts.

Exam trap

EX188 often tests the assumption that Podman uses dnsmasq (as Docker historically did) for container DNS, when the modern rootless default is actually aardvark-dns.

How to eliminate wrong answers

Option A is wrong because nscd is a legacy glibc name-service cache daemon for the host, not a per-network container DNS resolver, and it is not used by Podman for container-to-container resolution. Option C is wrong because dnsmasq is a general-purpose DNS/DHCP forwarder commonly used by Docker-style setups or libvirt, but Podman's default modern backend is aardvark-dns, not dnsmasq. Option D is wrong because bind9 is a full external DNS server product; Podman does not embed or default to BIND for container name resolution.

Practice this question →
46
MCQmedium

In a Podman Compose file, how do you define a custom network and connect a service to it?

A.Use the 'links:' directive inside the service block exclusively.
B.Add a 'network_mode' string directly pointing to an external shell script.
C.Define networks at the root level and reference them under each service configuration.
D.Configure networking exclusively via command-line environment variables.
AnswerC

Compose requires networks declared under the top-level networks key, then each service references the named network in its own networks list. This two-part structure attaches containers to the custom network, satisfying the requirement to define and connect services correctly.

Why this answer

In a Podman Compose file, custom networks are declared under a top-level networks: block, and each service references the desired network(s) under its own networks: key. This two-part structure is required by the Compose specification: the root-level declaration defines the network (driver, options, external flag), and the service-level reference attaches the service to it. This is how Compose wires services into shared networks for name resolution and isolation.

Exam trap

EX188 often tests the two-level structure requirement — candidates may forget that networks must be declared at the root and referenced per service, or may confuse links with network attachment.

How to eliminate wrong answers

Option A is wrong because the links: directive is a legacy feature for one-way container discovery and does not define or attach services to custom networks; it is deprecated in favor of user-defined networks. Option B is wrong because network_mode is used to set modes like host, bridge, or container:<name>, not to point at an external shell script — that is not a valid value. Option D is wrong because networking is configured declaratively in the Compose file, not exclusively via command-line environment variables; env vars may override some settings but are not the definition mechanism.

Practice this question →
47
Multi-Selectmedium

When publishing container ports using the Podman CLI, which THREE methods or syntaxes are valid for the -p / --publish flag? (Choose three)

Select 3 answers
A.-p 8080:80
B.-p 127.0.0.1:8080:80
C.-p container=80,host=8080
D.-p 80:8080:tcp:bind
E.-p 8080:80/udp
AnswersA, B, E

Publishing `-p 8080:80` maps host port 8080 to container port 80, satisfying the requirement for a valid `--publish` syntax. Podman accepts this `hostPort:containerPort` form directly, binding the specified host interface port to the container's exposed service port without extra flags.

Why this answer

Option A, `-p 8080:80`, is valid because the standard Podman/Docker publish syntax is `hostPort:containerPort`, mapping host port 8080 to container port 80 over the default TCP protocol. Option B, `-p 127.0.0.1:8080:80`, is valid because the full syntax `ip:hostPort:containerPort` binds the published port to a specific host interface (127.0.0.1) rather than all interfaces. Option E, `-p 8080:80/udp`, is valid because appending `/udp` (or `/tcp`) after the container port specifies the protocol for the published port.

Option C is invalid because Podman does not accept the key=value form `container=80,host=8080` for `--publish`. Option D is invalid because the protocol must be appended with a slash (e.g., `8080:80/tcp`) and cannot be followed by an extra `:bind` field in that position.

Exam trap

EX188 often tests whether candidates confuse Docker/Podman -p syntax with Kubernetes-style key=value port mappings or invent invalid protocol suffixes like ':tcp:bind'.

Practice this question →
48
MCQhard

You have a Kubernetes YAML manifest file named 'app.yaml' that defines a Pod with network settings. You want to deploy this directly as a Podman container/pod on your local system. Which command should you use?

A.podman-compose up --file app.yaml
B.podman run --kube app.yaml
C.podman apply -f app.yaml
D.podman play kube app.yaml
AnswerD

`podman play kube` reads a Kubernetes YAML manifest and creates the corresponding Podman pod and containers, translating Kubernetes constructs such as pod-level network namespaces into native Podman equivalents. This directly satisfies the stem's requirement to deploy an existing Kubernetes manifest locally without conversion or a cluster.

Why this answer

'podman play kube' reads a Kubernetes YAML manifest and creates the corresponding Podman pods and containers locally. It supports Pod, Deployment, and ConfigMap kinds, translating Kubernetes constructs into Podman equivalents. This is the correct command to deploy a Kubernetes manifest directly with Podman.

Exam trap

EX188 often tests the confusion between 'podman play kube' (Kubernetes YAML) and 'podman-compose' (Compose YAML), and candidates pick invalid flags like --kube on run.

How to eliminate wrong answers

Option A is wrong because 'podman-compose' consumes docker-compose YAML, not Kubernetes manifests, and 'up --file' is not the correct syntax for Kubernetes YAML. Option B is wrong because 'podman run --kube' is not a valid flag combination — run does not accept Kubernetes manifests. Option C is wrong because 'podman apply' is not a Podman subcommand; apply is a Kubernetes/OpenShift concept.

Practice this question →
49
Multi-Selectmedium

Which THREE configuration keys are valid within a service definition block in a Podman Compose file for managing container networking and ports? (Choose three.)

Select 3 answers
A.ports
B.interfaces
C.expose
D.firewall
E.networks
AnswersA, C, E

The ports key maps container ports to host ports within a service definition, directly satisfying the question's requirement for managing port publishing. It accepts a list of mappings or short syntax, and Podman Compose translates these into the corresponding port bindings when the container starts.

Why this answer

In a Podman Compose service definition, the ports key is valid because it publishes container ports to the host using the standard HOST:CONTAINER syntax, which is essential for managing port mappings. The expose key is also valid because it documents and exposes container ports to linked services on the internal network without publishing them to the host. The networks key is valid because it attaches a service to one or more named networks defined in the top-level networks section, enabling container-to-container networking.

The interfaces key is not a Compose service configuration key, as interface naming is handled by the container runtime rather than the Compose file. The firewall key is not part of the Compose specification; firewall rules are managed by the host's firewall tooling, not by service definitions.

Exam trap

EX188 often tests the distinction between ports (host publishing) and expose (internal only), and candidates may incorrectly select non-existent keys like interfaces or firewall.

Practice this question →
50
MCQeasy

Which Podman network mode completely isolates a container from any network communication, removing all interfaces except the loopback?

A.--network none
B.--network isolated
C.--network closed
D.--network disabled
AnswerA

`--network none` creates a network namespace containing only the loopback interface, so the container has no route to other containers, the host, or external networks. This directly satisfies the stem's requirement for complete isolation with all interfaces removed except loopback.

Why this answer

The `--network none` option in Podman creates a container with a completely isolated network namespace that contains only the loopback interface (lo). No veth pair, no bridge attachment, and no external connectivity is configured, so the container cannot send or receive any network traffic beyond itself. This is the canonical way to run a container with zero network exposure for security-sensitive workloads.

Exam trap

EX188 often tests whether candidates confuse the valid Podman network mode 'none' with plausible-sounding but nonexistent modes like 'isolated', 'closed', or 'disabled'.

How to eliminate wrong answers

Option B is wrong because `--network isolated` is not a valid Podman network mode — Podman supports none, host, bridge, slirp4netns, pasta, macvlan, ipvlan, and container:<id>, but not 'isolated'. Option C is wrong because `--network closed` is not a recognized Podman network mode and would produce an error. Option D is wrong because `--network disabled` is not a valid Podman network mode; the correct keyword for full network isolation is 'none'.

Practice this question →
51
Multi-Selectmedium

Which TWO statements are true regarding user-defined bridge networks in Podman? (Choose two)

Select 2 answers
A.They require the host firewall to be completely disabled to function.
B.Containers attached to different user-defined networks can communicate without explicit routing.
C.They prevent containers from communicating with the outside internet entirely.
D.They allow administrators to specify custom subnets and gateways during creation.
E.They provide automatic internal DNS resolution so containers can reach each other by name.
AnswersD, E

Podman accepts --subnet and --gateway flags at network creation, letting administrators define the address range and default gateway instead of accepting an auto-assigned range. This satisfies the stem's requirement by giving explicit control over the bridge network's IP addressing scheme.

Why this answer

Option D is correct because when creating a user-defined bridge network with `podman network create`, administrators can pass flags such as `--subnet` and `--gateway` to define custom CIDR ranges and gateway addresses instead of relying on Podman's default allocations. Option E is correct because Podman runs an internal DNS server (aardvark-dns) on user-defined networks, allowing containers to resolve each other by container name or network alias rather than by IP address. Option A is wrong because user-defined bridge networks rely on normal netfilter/NAT rules and do not require disabling the host firewall.

Option B is wrong because containers on separate user-defined bridge networks are isolated by default and cannot communicate without explicit routing or connecting a container to both networks. Option C is wrong because user-defined bridge networks still provide outbound connectivity to the internet via NAT/masquerading on the host.

Exam trap

EX188 often tests the difference between the default bridge network and user-defined networks, specifically that automatic DNS resolution and custom subnet configuration are exclusive to user-defined networks, while many candidates incorrectly assume these features are available on the default bridge.

Practice this question →
52
MCQhard

When deploying containers using Podman Compose, what is the default network driver assigned to user-defined networks created by compose if no driver is specified?

A.host
B.macvlan
C.overlay
D.bridge
AnswerD

Podman Compose creates user-defined networks using the bridge driver by default, giving containers on the same network layer-2 connectivity and name resolution. This matches the stem's unspecified-driver scenario, where no explicit driver means bridge is applied.

Why this answer

When Podman Compose creates a user-defined network without an explicit driver, it defaults to the bridge driver, matching Docker Compose behavior. The bridge driver creates a local software bridge on the host, giving containers on that network isolated L2 connectivity and automatic DNS-based name resolution among them.

Exam trap

EX188 often tests the assumption that Compose defaults to the host or overlay driver, when the correct default for user-defined networks is bridge.

How to eliminate wrong answers

Option A is wrong because the host driver removes network isolation entirely, sharing the host's network namespace — it is never the default for user-defined compose networks. Option B is wrong because macvlan assigns containers MAC addresses on the physical LAN, requiring a parent interface and often promiscuous mode; it is an explicit opt-in driver, not a default. Option C is wrong because overlay networks span multiple hosts (Swarm/Kubernetes style) and require a key-value store or orchestrator; Podman Compose on a single host does not default to overlay.

Practice this question →
53
MCQmedium

You need to configure a container so that its port 8080 maps to port 80 on the host's loopback interface only (127.0.0.1). Which syntax is correct?

A.podman run --net 127.0.0.1:80:8080 myapp
B.podman run -p 80:8080/127.0.0.1 myapp
C.podman run --publish 8080:80/lo myapp
D.podman run -p 127.0.0.1:80:8080 myapp
AnswerD

Binding the host address explicitly as 127.0.0.1:80:8080 restricts the published port to the loopback interface, satisfying the stem's requirement that only the host itself reach container port 8080 via host port 80. Omitting the address would publish on all interfaces, exposing the service externally.

Why this answer

The correct syntax for binding a published container port to a specific host IP is `-p HOST_IP:HOST_PORT:CONTAINER_PORT`. Option D, `-p 127.0.0.1:80:8080`, maps container port 8080 to host port 80, but only on the loopback interface 127.0.0.1, which is exactly what the question requires. This restricts external access so only processes on the host itself can reach the service.

Exam trap

EX188 often tests the exact ordering of the `-p` argument — candidates frequently swap host and container ports or misplace the IP, so memorise the format `IP:hostPort:containerPort/protocol`.

How to eliminate wrong answers

Option A is wrong because `--net` is used to specify a network mode (bridge, host, none, or a CNI network name), not to publish ports, and the value `127.0.0.1:80:8080` is not a valid network name. Option B is wrong because the syntax `80:8080/127.0.0.1` places the IP after a slash, which Podman interprets as a protocol suffix (tcp/udp), not a host IP binding. Option C is wrong because `8080:80/lo` reverses the port order and uses `lo` as a protocol, which is invalid; the correct order is host:container and the protocol must be tcp or udp.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Networking And Compose questions.

Start 20-question session