Saltstack¶
70 cards — 🟢 17 easy | 🟡 22 medium | 🔴 16 hard
🟢 Easy (17)¶
1. What is SaltStack's execution module?
Show answer
Execution modules are Python modules that define functions callable on minions via salt commands. They run ad-hoc tasks like pkg.install, service.restart, cmd.run. List available modules with salt '*' sys.list_modules.2. How do you install SaltStack on a system?
Show answer
Install Salt master: pip install salt or use repo packages (apt/yum). Configure /etc/salt/master (interface, file_roots, pillar_roots). Install minion: set master address in /etc/salt/minion. Start services, accept minion keys with salt-key -A. Verify with salt '*' test.ping.3. Explain the concept of grains in SaltStack.
Show answer
Grains are static data about a minion collected at startup: OS, CPU, memory, network, kernel. Used for targeting (salt -G 'os:Ubuntu' test.ping) and in state/pillar conditionals. Custom grains can be defined in /etc/salt/grains or grain modules.4. How can you use SaltStack to manage package installations across multiple systems?
Show answer
Use the pkg state module to manage packages: pkg.installed ensures presence, pkg.latest ensures newest version, pkg.removed uninstalls. Works across OS families (apt, yum, zypper). Supports single packages or pkgs list for multiples.5. Explain the purpose of SaltStack beacons.
Show answer
Beacons are minion-side monitors that watch system events (file changes, disk usage, service status, load) and emit events to the Salt event bus. They enable real-time monitoring without polling from the master. Configure in minion config or via beacon states.6. What is SaltStack and how does it manage infrastructure at scale?
Show answer
SaltStack is a Python-based infrastructure automation tool using a master-minion architecture over ZeroMQ. It provides remote execution, configuration management (states), and event-driven automation. Key components: master, minions, grains, pillars, states, and the event bus.7. Describe the architecture of a large-scale SaltStack deployment.
Show answer
Target minions using: glob (salt '*web*'), regex (-E), grain (-G 'os:CentOS'), pillar (-I 'role:web'), compound (-C 'G@os:Ubuntu and web*'), nodegroups, or IP ranges (-S '192.168.1.0/24'). Compound targeting combines multiple match types.8. What is the purpose of the Salt Pillar?
Show answer
Salt states are YAML+Jinja SLS files declaring desired system state. They're organized in the file_roots directory (default /srv/salt/). Apply with salt '*' state.apply or state.highstate. States use modules like pkg, file, service, user, and are idempotent by design.9. Explain the use of SaltStack states for managing users and groups.
Show answer
Pillars are secure, minion-specific data stored on the master (/srv/pillar/). Unlike grains (minion-generated), pillars are master-defined and only sent to targeted minions. Use for passwords, API keys, per-environment configs. Access via {{ pillar['key'] }} in states.10. Explain the SaltStack state requisites system.
Show answer
Grains are auto-detected minion metadata: OS, kernel, CPU, memory, IPs, virtualization type. View all grains with salt '*' grains.items. Set custom grains in /etc/salt/grains file or via grains.setval. Refreshed on minion restart or saltutil.sync_grains.11. What is SaltStack's role in managing cloud infrastructure?
Show answer
Salt master manages the infrastructure, stores states/pillars, and issues commands. Minions are agents on managed nodes that execute commands and report back. Communication uses ZeroMQ (pub/sub + req/rep). Master publishes, minions with matching targets execute and return results.12. Explain the difference between SaltStack and other configuration management tools.
Show answer
Salt formulas are pre-written, reusable state collections for common software (Apache, MySQL, Docker). Available on GitHub (saltstack-formulas). Install by cloning into file_roots. Configure via pillar data. Follow conventions: init.sls, map.jinja, pillar.example.13. How can you extend SaltStack functionality using custom grains and modules?
Show answer
Salt jobs are remote execution tasks tracked by a JID (Job ID). View active jobs: salt-run jobs.active. View results: salt-run jobs.lookup_jid14. What is the SaltStack Reactor system?
Show answer
Nodegroups are named sets of minions defined in master config for convenient targeting. Target with salt -N webservers state.apply. Supports compound matching syntax combining grains, globs, and lists.Remember: "Orchestrate = multi-minion coordination." salt-run state.orchestrate runs states across minions in order.
Example: Rolling restart: update web1, verify health, then web2, verify health.
15. Explain the SaltStack reactor system and its role in event-driven automation.
Show answer
Salt module types: Execution (run on minions: pkg, service, cmd), State (declarative desired state), Runner (run on master), Wheel (master management), Returner (send results externally), Grain (custom minion data), Renderer (template engines).16. Explain the role of SaltStack's external pillars.
Show answer
salt-key manages minion authentication keys: -L (list all), -A (accept all pending), -a (accept specific), -d (delete), -r (reject). Keys stored in /etc/salt/pki/. Minions must be accepted before they can receive commands.17. Describe SaltStack's support for conditional execution of states.
Show answer
Test mode (dry-run) shows what Salt would change without applying: salt '*' state.apply test=True. Reports each state as would-be-changed or already-correct. Essential for validating changes before production runs.🟡 Medium (22)¶
1. How does SaltStack handle service management and system restarts?
Show answer
Salt manages services via the service state module: service.running ensures a service is up, service.dead stops it, service.enabled controls boot behavior. Use watch to restart services when config files change.Remember: "SLS = SaLt State file." Written in YAML, defines desired state. Like Puppet manifests or Ansible playbooks.
2. Describe SaltStack's support for remote execution and state enforcement.
Show answer
Remote execution runs ad-hoc commands across minions (salt '*' cmd.run 'uptime'). State enforcement applies declarative configs from SLS files (salt '*' state.apply). Execution is imperative and one-off; states are idempotent and converge to desired state.Example: top.sls maps states to minions by target. base: 'web*': - webserver; 'db*': - database.
Remember: "top.sls = Salt's entry point. It says who gets what."
3. How can you implement SaltStack in a masterless (standalone) mode?
Show answer
Masterless mode runs salt-call --local on each minion without a central master. States and pillars are stored locally. Useful for: isolated systems, bootstrapping, CI/CD pipelines, or environments where a central master is impractical. Configure file_client: local in minion config.4. What is SaltStack's wheel system, and how is it used?
Show answer
The wheel system provides master-side management functions: key management (wheel.key.accept), config management, and file server operations. Called via salt-run or salt-api. Unlike execution modules (run on minions), wheel modules run on the master itself.5. What is the SaltStack Mine system, and how is it used?
Show answer
The mine system lets minions publish data to the master that other minions can query.Example: publish network IPs so a load balancer minion can auto-configure backends. Set mine_functions in minion config, query with mine.get. Updates on mine_interval.
6. How does Salt handle dependencies between states?
Show answer
Salt handles state dependencies with requisites: require (run after dependency succeeds), watch (run after dependency changes, triggers restart), onchanges (only run if dependency made changes), onfail (run if dependency fails). States without requisites run in file order.Remember: "Salt reactor = event-driven automation." When events match patterns, reactor runs states or commands.
Example: A minion coming online triggers a reactor that applies its highstate.
7. How does SaltStack handle system-level configuration files?
Show answer
Salt manages config files via file.managed (deploy from master), file.append, file.replace, and file.serialize. Use Jinja templates for dynamic content with pillar/grain data. Templates referenced as salt://path/to/file.jinja with template: jinja.8. Discuss the use of SaltStack with continuous integration/continuous deployment (CI/CD) pipelines.
Show answer
Jinja is Salt's default templating engine for SLS files. Use {{ grains.os }} or {{ pillar.get('key', 'default') }} for dynamic values. Supports conditionals, loops, and filters. Avoid heavy Jinja logic; prefer pillar data and simple conditionals.9. What are SaltStack formulas, and how do they promote reusability?
Show answer
The orchestrate runner (state.orchestrate) coordinates multi-minion workflows from the master. Unlike regular states, it runs sequentially across multiple minions with ordering control.Example: upgrade DB servers first, then app servers, then LBs.
10. Explain the SaltStack Salt API and its role in remote execution.
Show answer
Runners execute on the salt master (not minions) via salt-run. Built-in runners: manage.status (check minion connectivity), jobs.active (list running jobs), state.orchestrate (multi-minion workflows). Custom runners go in /srv/salt/_runners/.Remember: "salt-ssh = agentless Salt." No minion needed — uses SSH like Ansible. Useful for bootstrapping or locked-down environments.
Example: salt-ssh '*' state.apply runs states over SSH.
11. Describe SaltStack's integration with version control systems like Git.
Show answer
Salt environments map to different file_roots paths. Minions are assigned via environment config or targeting. Use for separating dev/staging/prod state trees and pillar data. Each environment has its own top.sls.12. Explain the concept of SaltStack's file server backends.
Show answer
Pillar data is assigned to minions via top.sls in /srv/pillar/. Access in states with pillar.get('key', 'default'). Refresh with saltutil.refresh_pillar. Pillar data is encrypted in transit and only sent to matching minions.13. What is a Salt state file?
Show answer
Salt SSH provides agentless execution over SSH without requiring minion installation. Configure targets in /etc/salt/roster. Supports states and execution modules but is slower than ZeroMQ transport. Useful for bootstrapping, network devices, or restricted environments.14. How does SaltStack handle orchestration and job management?
Show answer
Salt's built-in file server distributes files from master to minions. Supports multiple backends: roots (local filesystem), git (gitfs), S3, and svn. Files referenced in states as salt://path/to/file. Use gitfs for version-controlled state/pillar management.15. Explain SaltStack's grains filtering and targeting mechanisms.
Show answer
Returners send minion job results to external systems instead of (or in addition to) the master. Built-in returners: MySQL, PostgreSQL, Redis, Elasticsearch, syslog, Slack. Useful for centralized logging, monitoring integration, and audit trails.16. How does Salt handle target specification for remote execution?
Show answer
Proxy minions manage devices that can't run a regular minion (network switches, IoT, APIs). The proxy process runs on a separate host and translates Salt commands to device-specific protocols (NETCONF, REST, SSH). Configure with proxytype in pillar data.17. How does Salt ensure idempotence in configurations?
Show answer
Jinja macros create reusable template functions in Salt SLS files. Also use map.jinja pattern for OS-specific package/config mappings. Import with {% from 'map.jinja' import config %}. Keeps state files DRY and maintainable.18. Explain how SaltStack supports event-driven automation.
Show answer
top.sls maps minions to states using targeting (glob, grain, pillar, compound). Multiple environments can have separate top files. Applied via state.highstate. Defines which states apply to which minions.19. Describe the Salt Master and Salt Minion components.
Show answer
GitFS serves Salt states directly from git repos. Branches/tags map to Salt environments. Configure gitfs_remotes in master config. Enables GitOps workflow: push to repo, Salt picks up changes automatically.20. What is SaltStack's Minion configuration file, and what parameters can be configured?
Show answer
Salt's schedule system runs states or functions at defined intervals on minions or master. Configured in minion/master config or via pillar. Enables periodic enforcement without external cron.Example: run highstate every 24 hours.
21. How does SaltStack handle orchestration across multiple environments?
Show answer
Salt supports multiple output formats: nested (default), json, yaml, txt, table, pprint. Specify with --out flag. Useful for scripting and integration. Custom outputters can be written as Python modules.22. What is SaltStack's runner system, and how does it differ from execution modules?
Show answer
Salt supports Windows minions with Windows-specific modules: win_pkg, win_service, win_firewall, win_iis. Install via MSI or bootstrap script. States work cross-platform; Salt auto-selects correct module. Use grains for OS-specific conditionals.🔴 Hard (16)¶
1. Discuss the role of SaltStack beacons in real-time monitoring.
Show answer
Beacons monitor minion system events (file changes, load, service status) in real-time and emit events to the Salt Master. Combined with reactors, they enable automated responses. Example: an inotify beacon watches file changes and triggers a reactor to enforce state.Remember: "Salt = fast remote execution + config management." The master-minion architecture uses ZeroMQ for speed.
Fun fact: Salt can manage 10,000+ minions from a single master due to its async message bus.
2. How can you secure communication between Salt Master and Minions?
Show answer
Salt uses AES-256 encryption for all master-minion communication over ZeroMQ. Key management: minions send public keys to master, admin accepts via salt-key. Enable require_auth and rotate keys periodically. Use salt-call --local for testing without master trust.Example: salt '*' test.ping — pings all minions. salt 'web*' cmd.run 'uptime' — runs uptime on web servers.
Remember: "salt 'target' module.function 'args' — that's the basic pattern."
3. Describe SaltStack's external authentication mechanisms.
Show answer
Salt supports external auth (salt-api, LDAP, PAM) via the external_auth config. Map external users/groups to Salt functions. Also supports token-based auth for salt-api and eauth for CLI.Remember: "Grains = static facts (like Facter), Pillars = dynamic secrets (like Hiera)."
Example: salt '*' grains.item os shows each minion's OS.
4. Discuss the impact of SaltStack changes on system performance during a run.
Show answer
Salt runs can impact performance through: CPU spikes during state compilation (especially with Jinja rendering), I/O from package installs or file operations, and network load from pillar/file transfers. Mitigate with batch mode (--batch-size), async execution, and avoiding unnecessary Jinja complexity.5. What are the considerations for migrating from SaltStack 2019 to later versions?
Show answer
Key migration considerations: check deprecated modules/states, test states in dev first, review changelog for breaking changes, update formulas and custom modules, verify ZeroMQ compatibility, test pillar/grain behavior, and run salt-call state.show_sls to preview changes before applying.6. How can you implement SaltStack code testing and linting in a development workflow?
Show answer
Test Salt code with: salt-call --local state.show_sls for syntax checks, kitchen-salt for integration testing, pytest-salt for unit tests, salt-lint for style checking. CI pipeline: lint -> render -> test.apply (dry-run) -> full apply in disposable environment.7. How does SaltStack handle custom states for unique system configurations?
Show answer
The reactor system responds to events on the Salt event bus by triggering actions. Configure in master config with event tag patterns mapped to reactor SLS files. Use cases: auto-accept keys, remediate alerts, trigger deploys on git push. Reactor SLS files use local/runner/wheel calls.8. Explain the use of SaltStack runners for managing complex tasks.
Show answer
Debug Salt issues with: salt-call --local -l debug state.apply for verbose output, salt-run manage.status for connectivity, salt '*' test.ping for reachability. Check /var/log/salt/ logs. Common issues: key mismatches, ZeroMQ timeouts, pillar render errors, minion cache staleness.9. How does SaltStack handle file content updates without replacing the entire file?
Show answer
Salt Cloud provisions VMs across cloud providers (AWS, GCP, Azure, DigitalOcean). Configure profiles and providers in /etc/salt/cloud.*. Provision with salt-cloud -p profile_name vm_name. Auto-installs minion and connects to master. Supports maps for multi-VM deploys.10. Discuss the role of SaltStack states in creating high-level abstractions.
Show answer
Salt's event bus (ZeroMQ) carries all system events: job returns, minion start/stop, auth events, beacon emissions. Monitor with salt-run state.event pretty=True. Custom events via event.send. The reactor system subscribes to event tags for automated responses.11. Explain the SaltStack External File Server (EFS) and its use cases.
Show answer
Scale Salt with: syndic masters (hierarchical topology), multiple file/pillar roots, salt-api for REST access, async/batch execution, gitfs for distributed state management, and tuning worker_threads and ZeroMQ settings. For 10k+ minions, consider syndic or salt-proxy architecture.12. What is SaltStack's top file, and how is it used?
Show answer
Debug slow Salt runs: enable -l debug logging, check state.show_highstate for state count, profile Jinja rendering, check pillar size (large pillars slow compilation). Network: test ZeroMQ connectivity, check firewall (ports 4505/4506), verify DNS. Use salt-run manage.status for unresponsive minions.13. How does SaltStack support multi-cloud or hybrid cloud environments?
Show answer
Highstate applies all states from top.sls to matching minions (salt '*' state.highstate). Orchestration (state.orchestrate) coordinates across multiple minions with ordering.Key difference: highstate is per-minion convergence; orchestration is master-controlled multi-minion workflow.
14. How can you implement SaltStack in a high availability (HA) configuration?
Show answer
Write custom execution modules in Python, place in /srv/salt/_modules/. Sync to minions with saltutil.sync_modules. Test with salt-call --local my_module.my_function arg. Same pattern for custom states, grains, returners, and runners.15. Explain how SaltStack integrates with other DevOps tools in the toolchain.
Show answer
Multi-master setup provides HA: minions connect to multiple masters. All masters share the same keys, file_roots, and pillar data (use gitfs or shared storage). Failover is automatic. Not active-active for jobs; use syndic for hierarchical scaling.16. Discuss SaltStack's approach to handling secrets and sensitive data securely.