OpenStack Interview Questions and Answers

OpenStack interviews combine architecture and operations:

Modern screens favor the unified openstack CLI and scenario answers over obsolete MCQs about removed daemons.

A strong answer is:

"OpenStack interviews test whether I can trace a VM from image and flavor through network attachment to a reachable floating IP, explain Keystone authorization, and troubleshoot using the deployment's actual logging and service layout."

What interviewers are testing: whether you map each core service to its control-plane responsibility—not just recite acronyms.

OpenStack 2026.1 Gazpacho, released April 1, 2026, is the current maintained coordinated release at the time of this update. Core services still form a modular control plane:

Supporting infrastructure commonly includes SQL databases, a message bus such as RabbitMQ, and caching layers depending on the deployment architecture.

A strong answer is:

"Keystone authenticates and catalogs services; Nova schedules VMs; Neutron provides tenant networks and routing; Glance stores images; Cinder provides persistent disks. I explain how those APIs connect, not only what each acronym means."

What interviewers are testing: whether you distinguish Magnum (Kubernetes on OpenStack) from OpenStack-Helm (OpenStack on Kubernetes).

These are often confused:

Magnum does not deploy OpenStack on Kubernetes. If interviewers ask about running OpenStack control-plane components on Kubernetes, OpenStack-Helm is the relevant example.

A strong answer is:

"Magnum gives tenants Kubernetes clusters as an OpenStack service. OpenStack-Helm is for operators who run OpenStack's own services on Kubernetes—I do not describe Magnum as 'OpenStack on Kubernetes.'"

What interviewers are testing: whether you pick the right deployment model and explain how operators find logs and restart services in that stack.

Interviewers care whether you know how to find logs and restart services in your deployment model—not one universal filesystem layout.

A strong answer is:

"Kolla-Ansible delivers containerized OpenStack with Ansible; OpenStack-Helm runs OpenStack on Kubernetes. In either case I troubleshoot through the deployment's service containers, systemd units, or Helm releases rather than assuming legacy package paths."

What interviewers are testing: whether you separate Keystone identity objects—domain, project, user, role—and use modern role names.

Modern Keystone deployments commonly use default roles such as reader, member, manager, admin, and service, depending on scope and purpose. Assignment example:

openstack role add --project demo --user demo member

A strong answer is:

"Domains isolate administrative boundaries; projects scope resources; roles define what a user may do inside a project. I use the unified openstack CLI and modern role names like member and admin."

What interviewers are testing: Whether you can trace authentication from Keystone token issuance and scope through service-catalog endpoint discovery, downstream token validation, and authorization failures such as 401/403.

1. User or application authenticates to Keystone.
2. Keystone returns a token and a service catalog of API endpoints.
3. Other services (Nova, Neutron, Cinder) validate the token and authorize the request.

Invalid or expired authentication commonly results in 401 Unauthorized. A valid token with insufficient role, scope, or policy authorization typically results in 403 Forbidden.

Memcached (or equivalent) often caches tokens for performance, but the exact Keystone deployment stack varies by distribution—do not memorize one legacy httpd + memcached answer as universal truth.

A strong answer is:

"Keystone issues a token and endpoint catalog; every API call presents that token. When debugging auth failures I check scope, role assignment, token expiry, and clock skew before blaming the downstream service."

What interviewers are testing: whether you distinguish creating a Keystone role object from editing policy rules that grant API permissions.

Create the role in Keystone:

openstack role create observability_reader
openstack role add --project monitoring --user alice observability_reader

Creating a role does not require editing policy.json. Policy files control which API actions each role may perform; they do not create the role object itself.

A strong answer is:

"Roles are Keystone objects created with openstack role create; policy rules then define what that role can do. I separate identity objects from policy enforcement."

What interviewers are testing: Whether you understand Glance as an image metadata/API service with pluggable storage backends and can separate current architecture from removed glance-registry designs.

Glance stores and catalogs VM images.

Modern Glance is centered on the Glance API service. The old glance-registry daemon was removed years ago—do not teach a two-daemon registry/API model in 2026 interviews.

Typical workflow:

openstack image create "cirros" \
  --file cirros.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --public

Backends may be local filesystem, Ceph RBD, Swift, or other object stores depending on glance_store configuration.

A strong answer is:

"Glance is the image API and metadata service; storage backends are pluggable. I know glance-registry is historical and I troubleshoot image uploads through the API and configured backend."

What interviewers are testing: whether you trace a boot request through nova-api, scheduler, Placement inventory, and nova-compute.

openstack server create --flavor m1.small --image cirros --network private demo-vm
openstack server list

A strong answer is:

"Nova-api accepts requests, the scheduler picks a host using Placement inventory, and nova-compute talks to the hypervisor. I trace boot failures across scheduler, compute, and image/network dependencies."

What interviewers are testing: whether you differentiate flavor templates from project quota limits when instance creates fail.

Flavors define instance sizing (vCPU, RAM, disk). Create one with the unified CLI:

openstack flavor create --public m1.tiny --ram 512 --disk 1 --vcpus 1

Quotas limit project consumption:

openstack quota show --project demo

A strong answer is:

"Flavors are hardware templates; quotas cap project usage. When a create fails with quota errors I inspect openstack quota show before chasing hypervisor issues."

What interviewers are testing: Whether you trace an instance build through API state, scheduler/Placement, image, networking, compute assignment, and hypervisor evidence in that order.

Ordered checklist:

1. openstack server show <id> — inspect VM status, fault details, task state, and host if scheduling progressed far enough
2. openstack compute service list — verify compute services
3. Check scheduler/Placement capacity and allocation failures
4. Verify image state
5. Verify Neutron port creation/binding and subnet IP availability
6. Inspect compute/hypervisor logs if a host was selected

A strong answer is:

"BUILD usually means scheduler, compute, image, network, or hypervisor failure. I read the instance fault, verify compute services, then narrow to the scheduled host's logs."

What interviewers are testing: Whether you distinguish Neutron's logical L3 routing/NAT function from L2 port switching and understand that implementation differs between OVS-agent and OVN deployments.

Neutron routers provide tenant L3 routing and NAT. In classic ML2/OVS deployments this is implemented by neutron-l3-agent; OVN-based deployments implement the same logical function through OVN's distributed/centralized routing components.

The Open vSwitch agent handles virtual switching on hypervisors—it is not the service that owns L3 routing/NAT by itself.

openstack network agent list
openstack router show public-router

A strong answer is:

"L3 routing and NAT are Neutron router functions. In ML2/OVS clouds that is traditionally neutron-l3-agent; in OVN clouds the same logical behavior is implemented through OVN routing components. OVS agents handle L2 connectivity on compute nodes—I do not confuse the two."

What interviewers are testing: whether you manage port-level Neutron firewall rules with the unified CLI instead of legacy nova commands.

Security groups are Neutron-managed stateful firewall rules attached to ports:

openstack security group rule create --ingress --protocol tcp --dst-port 22 \
  --remote-ip 203.0.113.0/24 default

Prefer the openstack CLI over deprecated nova secgroup-* commands in modern material.

A strong answer is:

"Security groups are port-level Neutron policies. I add rules with openstack security group rule create and verify the instance port actually uses the intended group."

What interviewers are testing: Whether you trace connectivity from instance port → subnet/router → external gateway/floating IP → security policy rather than immediately debugging the guest OS.

Checklist:

1. Tenant network vs provider/external network attachment
2. Router gateway on external network
3. Floating IP associated to the correct port
4. Security groups, subnet configuration, router interfaces, and any static routes
5. Neutron agent health — openstack network agent list (in agent-based deployments, check L3/OVS agent health; in OVN environments, check the relevant OVN controllers, gateways, and Neutron service state)
6. DNS/NAT only after L3 path is correct

openstack floating ip create public
openstack server add floating ip demo-vm <floating-ip>

A strong answer is:

"I verify the instance port, router gateway, floating IP association, and security groups before blaming the hypervisor. In agent-based deployments I check L3/OVS agent health; in OVN I check OVN controllers and gateways."

What interviewers are testing: whether you attach persistent block volumes through Cinder and diagnose attach failures at the API layer.

Cinder provides persistent block storage to instances.

openstack volume create --size 10 data-vol
openstack server add volume demo-vm data-vol

A cinder-volume service typically runs per storage backend (Ceph RBD, iSCSI LVM, vendor driver).

A strong answer is:

"Cinder volumes attach to instances as block devices. I create and attach with the openstack CLI and troubleshoot attach failures through Cinder and compute logs."

What interviewers are testing: whether you differentiate on-backend snapshots from offloaded backups with configurable backup stores.

Swift is one possible backup backend—not a universal architectural rule.

A strong answer is:

"A volume snapshot is a point-in-time Cinder snapshot tied to the volume/backend's snapshot implementation. A backup is a separate Cinder backup operation written through the configured backup driver and intended for recovery independent of the active volume lifecycle."

What interviewers are testing: whether you match object-storage workloads to Swift versus low-latency Cinder block I/O.

Swift stores objects in containers—good for backups, static assets, Glance backends, and large unstructured data.

openstack container create mycontainer
openstack object create mycontainer /path/to/file
openstack object list mycontainer

The standalone swift CLI may still be encountered in existing environments, but the unified client is the teaching baseline here.

Object storage fits HTTP-accessible, replicated object workloads where block-device semantics and low-latency random writes are not required.

A strong answer is:

"Swift is for durable object storage at scale. I use the unified openstack container and openstack object commands for interviews and scripts; the standalone swift client may still exist in older environments. Databases and VM disks belong on Cinder block storage."

What interviewers are testing: whether you debug failed orchestration through stack status, events, and outputs—not only the template syntax.

Heat orchestrates infrastructure from templates. Heat primarily uses HOT (Heat Orchestration Template) YAML; environments may also encounter compatibility with AWS-style template/resource concepts.

openstack stack create -t app.yaml -e env.yaml mystack
openstack stack show mystack
openstack stack output list mystack

Stacks can be updated while running when the template change supports it.

A strong answer is:

"Heat turns templates into collections of OpenStack resources. I check stack status, events, and outputs when a deployment fails halfway."

What interviewers are testing: whether you standardize on the unified openstack CLI instead of legacy per-service clients.

Modern OpenStack distributions emphasize the openstack command instead of legacy per-service clients:

One OpenStackClient authentication configuration—such as environment variables from an openrc, clouds.yaml, or another supported auth plugin—can drive commands across services.

A strong answer is:

"I standardize on the openstack CLI for interviews and production scripts. Legacy nova/neutron/cinder clients are historical compatibility, not the teaching baseline in 2026."

What interviewers are testing: Whether you understand where Ceph can sit beneath Glance, Cinder, and Nova and can distinguish an OpenStack API problem from a degraded storage backend.

Common integration points:

Benefits: unified storage cluster, snapshots/clones, horizontal scaling.

Trade-offs: operating Ceph correctly (PG balance, OSD failure, latency) becomes part of cloud operations.

A strong answer is:

"Ceph often backs Glance and Cinder in production clouds. I explain how RBD volumes and images map to pools and why Ceph health affects instance and volume operations."

What interviewers are testing: whether you remove single points of failure across API, database, messaging, and storage—not just one layer.

HA patterns:

• Stateless API services behind load balancers (multiple Nova/Neutron API workers)
• Database clustering for MariaDB/MySQL (Galera or managed DB)
• RabbitMQ clustering or alternative messaging HA
• Keystone and other API caches deployed redundantly according to the distribution's supported architecture
• Ceph or replicated storage for Glance/Cinder data planes

Upgrades and maintenance require understanding which components can roll restart vs which need quorum safety.

A strong answer is:

"I remove single points of failure in API, database, message bus, and storage layers. HA is systemic—one clustered service does not HA the whole cloud."

What interviewers are testing: whether you correlate hung APIs and stuck spawns with message-bus queue health.

RabbitMQ (or the configured message bus) carries RPC between OpenStack services.

rabbitmqctl status
rabbitmq-diagnostics check_running
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

On large clusters, scope queue inspection rather than dumping every queue blindly.

Symptoms of messaging trouble: services time out, instances stuck spawning, API calls hang.

A strong answer is:

"When APIs hang or services stop progressing I check the message bus queues and connectivity—not only the API logs."

What interviewers are testing: whether you find logs deployment-aware—Kolla, Helm, systemd—instead of assuming fixed legacy paths.

There is no single universal log path in 2026 deployments.

Do not teach fixed /var/log/cinder/api.log paths as guaranteed truth.

A strong answer is:

"For Kolla-Ansible I check /var/log/kolla/<service>/ or the configured centralized logging backend first; I don't assume docker logs contains the OpenStack service log. For other deployment methods I use journald, pod logs, or the operator's log aggregation stack."

What interviewers are testing: Whether you treat control-plane database backup as a coordinated, restorable recovery process rather than simply running a dump command.

Control-plane state lives in SQL databases (Keystone, Nova, Neutron, Cinder, Glance, Heat schemas).

For logical backups, use a consistent database dump or the deployment/vendor-supported backup tooling. In clustered database deployments, follow the documented Galera/database backup procedure rather than assuming a generic mysqldump --all-databases is sufficient.

Use coordinated backup procedures from your distribution. Restore drills matter as much as dumps.

A strong answer is:

"I back up the OpenStack databases with consistent dumps or the vendor's supported backup tool, then validate restore in staging before relying on it in an incident."

What interviewers are testing: whether you map a down agent to host, service, and tenant impact before restarting.

Investigation steps:

1. Identify agent type (OVS, L3, DHCP, metadata) and host
2. Check agent container/service on that host
3. Review recent deploy, reboot, or upgrade on the node
4. Verify RabbitMQ connectivity and credentials
5. Restart the agent service only after understanding blast radius

Impact depends on agent type—for example, an L3-agent failure may affect routing handled by that network node, while an OVS-agent failure may affect local port binding/connectivity on its compute host.

A strong answer is:

"I map the down agent to a host and service, fix the underlying process or connectivity issue, and consider tenant impact based on agent type before restarting."

What interviewers are testing: whether you use Placement inventory and hypervisor stats to explain scheduling failures.

Placement tracks inventory consumed by Nova scheduling.

openstack resource provider list
openstack hypervisor stats
openstack compute service list

Watch for CPU, memory, disk, custom-resource inventory, allocation ratios, and uneven compute utilization. Check Neutron separately for subnet/IP exhaustion.

A strong answer is:

"Placement and hypervisor stats show where capacity is actually consumed. I use them before blaming 'mysterious' scheduling failures on Nova itself."

What interviewers are testing: Whether you understand that OpenStack upgrades are service- and deployment-tool-specific, with database migrations, compatibility windows, rollback/recovery planning, and SLURP rules that must be verified per component.

1. Read release notes for the target series (for example 2026.1 Gazpacho)
2. Follow the deployment tool/vendor and individual project's supported upgrade path. Normal upgrades are commonly adjacent-release upgrades, but 2026.1 Gazpacho is a SLURP (Skip-Level Upgrade Release), so supported components may allow a skip-level upgrade from the previous SLURP release—for example Nova supports 2025.1 → 2026.1, skipping 2025.2 Flamingo. Verify every service and deployment tool before skipping a release.
3. Backup databases and configuration
4. Upgrade control plane services in the documented order
5. Roll compute/network nodes with workload evacuation where required
6. Validate API, networking, volume attach, and image create smoke tests

A strong answer is:

"2026.1 is a SLURP release, but I do not assume the whole cloud can skip a release because Nova can. I verify the supported path for every service and the deployment tool, back up state, then validate core workflows after each phase."