IaC Playground
Real Ansible lab with a control node and target container
Lab Architecture
🤖
Control Node
Ansible installed
10.99.0.x
SSH + Ansible
🎯
Target Node
Managed host
10.99.0.y
Both containers on vmbr99 (isolated). Control node has SSH access to target only.
Connecting to lab engine...
Checking if real Linux environments are available
Real Container Lab
Launch an ephemeral LXC container for hands-on practice. Auto-destroys after 60 minutes.
Prefer offline mode?
Provisioning a real Linux container on isolated infrastructure
Creating LXC container on Proxmox...
Booting Alpine Linux & installing tools...
Opening live terminal session...
!
Failed to create lab
Connected to live container -- this is a real, isolated Linux environment
Simulation Mode -- Could not reach lab engine. Using client-side sandbox.
Challenges
Get familiar with Ansible on the control node
○ Check your Ansible version
- Run ansible --version to see the installed version
- Note the config file path and Python version shown in the output
- This confirms Ansible is properly installed and ready to use
ansible --version 💡 Ansible requires Python. The version output shows which Python interpreter it uses.
○ View the inventory file
- Open /etc/ansible/hosts with cat or less to see defined hosts
- Look for the [target] group — this is the managed host for this lab
- Inventory files use INI or YAML format to list hosts and groups
cat /etc/ansible/hosts 💡 The inventory file tells Ansible which machines to manage. Groups are defined in [brackets].
○ Ping the target node
- Run the ping module against the "target" host group
- A successful ping returns "pong" in green — this tests SSH connectivity, not ICMP
- If it fails, check SSH keys and inventory configuration
ansible target -m ping 💡 The Ansible ping module tests SSH access, not network ICMP ping. It verifies Ansible can connect and run Python on the remote host.
Expected:
target | SUCCESS => { "ping": "pong" } ○ Run an ad-hoc shell command
- Use the shell module with -m shell and pass a command with -a
- The -a flag passes arguments (the actual command) to the module
- Check the output to confirm you can execute arbitrary commands on the target
ansible target -m shell -a "uname -a" 💡 The shell module runs commands through /bin/sh. Use the command module instead if you do not need shell features like pipes or redirects.
○ Gather facts about the target
- The setup module collects detailed system information (facts) from remote hosts
- Pipe through head -50 to see the first portion without flooding the terminal
- Facts include OS, IP addresses, memory, CPU, and more — these become variables in playbooks
ansible target -m setup | head -50 💡 Facts are automatically gathered at playbook start unless you set gather_facts: false. Use ansible_os_family, ansible_hostname, etc. in templates.
Run quick tasks without writing a playbook
○ Check target uptime
- Use the command module to run uptime on the target
- The command module is the default — it runs commands directly without a shell
- Review the output to see how long the target has been running
ansible target -m command -a "uptime" 💡 The command module does not support shell operators like pipes (|) or redirects (>). Use the shell module if you need those.
○ Install a package with apk
- Use the apk module to install curl on the Alpine target
- The name parameter specifies the package; state=present ensures it is installed
- Ansible will skip the task if curl is already present (idempotent behavior)
ansible target -m apk -a "name=curl state=present" 💡 This lab runs Alpine Linux, which uses apk (not apt or yum). The state parameter can be present, absent, or latest.
Expected:
target | CHANGED or target | SUCCESS (if already installed)
○ Copy content to a remote file
- Use the copy module with the content parameter to write text directly to a file
- The dest parameter sets the file path on the target host
- This is useful for quick file creation without having a local source file
ansible target -m copy -a "content='Hello from Ansible' dest=/tmp/hello.txt" 💡 The copy module can also copy local files using src instead of content. Add mode=0644 to set permissions.
○ Read the remote file
- Use the command module to cat the file you just created on the target
- The output appears under stdout in the Ansible response
- This verifies the previous copy task worked correctly
ansible target -m command -a "cat /tmp/hello.txt" 💡 For fetching remote files to the control node, use the fetch module instead. The command module just shows output.
○ Remove the remote file
- Use the file module with state=absent to delete the file
- The path parameter specifies which file to remove
- Running this again will still succeed — Ansible is idempotent, so deleting an absent file is a no-op
ansible target -m file -a "path=/tmp/hello.txt state=absent" 💡 The file module manages files, directories, and symlinks. Use state=directory to create dirs, state=link for symlinks.
Expected:
target | CHANGED (first run) or target | SUCCESS (already absent)
Create and execute Ansible playbooks
○ Create a package installation playbook
- Create a file called install.yml using vi, nano, or cat with a heredoc
- Start with --- (YAML document marker), then define a play with name:, hosts: target, and become: yes
- Under tasks:, add two entries using the apk module to install curl and wget with state: present
- YAML uses 2-space indentation — do not use tabs
cat > install.yml << 'EOF'
---
- name: Install packages
hosts: target
become: yes
tasks:
- name: Install curl
apk:
name: curl
state: present
- name: Install wget
apk:
name: wget
state: present
EOF 💡 become: yes tells Ansible to use privilege escalation (sudo/doas). Each task needs a name: for readability and a module with its parameters.
○ Run the playbook
- Execute the playbook with ansible-playbook install.yml
- Watch the output — each task shows ok (no change), changed (action taken), or failed
- The PLAY RECAP at the end summarizes results for each host
ansible-playbook install.yml 💡 Add -v for verbose output, -vv for more detail, or -vvv for full connection debugging.
Expected:
PLAY RECAP with ok=3 changed=2 (on first run)
○ Verify packages on the target
- Use an ad-hoc command to check that curl and wget are installed
- The which command shows the full path if the binary exists
- Both should return valid paths confirming the playbook worked
ansible target -m shell -a "which curl && which wget" 💡 You can also use apk info curl to see package details, or run curl --version to verify it works.
○ Add a user creation task
- Edit install.yml and add a new task using the user module
- Set name: labuser, state: present, and optionally shell: /bin/sh
- The user module handles creating the user, home directory, and group automatically
cat >> install.yml << 'EOF'
- name: Create lab user
user:
name: labuser
state: present
shell: /bin/sh
EOF 💡 The user module supports uid, groups, password (hashed), and create_home parameters. Use ansible-doc user to see all options.
○ Dry-run with check mode
- Run the playbook with --check to simulate execution without making changes
- Check mode predicts what would change — tasks show changed but nothing is actually modified
- This is essential for verifying playbooks before applying to production
ansible-playbook install.yml --check 💡 Some modules do not support check mode and will be skipped. Add --diff to also see file content changes that would occur.
Use Jinja2 templates and variables in playbooks
○ Define variables in a playbook
- Create a new playbook called template-demo.yml
- Add a vars: section under the play level (same indent as tasks:)
- Define variables like app_name, app_port, and app_env — these become available in tasks and templates
cat > template-demo.yml << 'EOF'
---
- name: Template demo
hosts: target
become: yes
vars:
app_name: myapp
app_port: 8080
app_env: production
tasks:
- name: Show variables
debug:
msg: "App {{ app_name }} on port {{ app_port }}"
EOF 💡 Variables use {{ double_braces }} in Jinja2 syntax. When a value starts with {{ in YAML, wrap the whole value in quotes to avoid parsing errors.
○ Create a Jinja2 template file
- Create a file called app.conf.j2 — the .j2 extension marks it as a Jinja2 template
- Use {{ variable_name }} syntax to insert variables
- You can also use {% if %} blocks and {% for %} loops in templates
cat > app.conf.j2 << 'EOF'
# Application Configuration
# Generated by Ansible - do not edit manually
[app]
name = {{ app_name }}
port = {{ app_port }}
environment = {{ app_env }}
hostname = {{ ansible_hostname }}
os_family = {{ ansible_os_family }}
EOF 💡 Jinja2 templates support filters like {{ var | default("fallback") }}, {{ var | upper }}, and {{ list | join(",") }}.
○ Deploy the template to the target
- Add a task using the template module with src: pointing to your .j2 file
- Set dest: to the target path where the rendered config should land
- Ansible renders the template locally, substituting all variables, then copies the result
cat >> template-demo.yml << 'EOF'
- name: Deploy app config
template:
src: app.conf.j2
dest: /tmp/app.conf
mode: "0644"
EOF 💡 The template module always transfers the file, but only reports changed if the content actually differs from what is on disk.
○ Use facts in the template
- Run the playbook — Ansible automatically gathers facts before executing tasks
- The template already references ansible_hostname and ansible_os_family
- Facts are available as variables in any task or template without declaring them in vars:
ansible-playbook template-demo.yml 💡 Run ansible target -m setup to see all available facts. Common ones: ansible_default_ipv4.address, ansible_memtotal_mb, ansible_distribution.
Expected:
PLAY RECAP with changed=1 for the template task
○ Verify the rendered config
- Read the deployed file on the target to confirm variables were substituted
- You should see the actual hostname and OS instead of {{ }} placeholders
- This confirms the template engine processed everything correctly
ansible target -m command -a "cat /tmp/app.conf" 💡 If you see raw {{ variable }} in the output, the template was copied with the copy module instead of the template module — make sure you use template:.
Expected:
A rendered config file with real values replacing all {{ }} placeholders Build reactive, conditional automation
○ Create a handler that restarts a service
- Create a playbook called handler-demo.yml with a handlers: section at the play level
- Handlers are defined like tasks but only run when triggered by notify:
- Define a handler with a descriptive name like "Restart crond" using the service module
cat > handler-demo.yml << 'EOF'
---
- name: Handler and conditional demo
hosts: target
become: yes
tasks:
- name: Ensure crond is installed
apk:
name: dcron
state: present
- name: Start crond service
service:
name: dcron
state: started
- name: Deploy cron config
copy:
content: "# Managed by Ansible\n*/5 * * * * echo heartbeat\n"
dest: /etc/crontabs/root
mode: "0600"
notify: Restart crond
handlers:
- name: Restart crond
service:
name: dcron
state: restarted
EOF 💡 Handlers run once at the end of the play, even if notified multiple times. Use meta: flush_handlers to force them to run mid-play.
○ Trigger the handler with notify
- Run the playbook — the Deploy cron config task includes notify: Restart crond
- On the first run, the copy task will be "changed", so the handler fires
- Run it again — the copy task will be "ok" (no change), so the handler is skipped
ansible-playbook handler-demo.yml 💡 The notify value must exactly match the handler name (case-sensitive). You can notify multiple handlers with a list.
Expected:
First run: RUNNING HANDLER [Restart crond]. Second run: no handler triggered.
○ Add a when conditional
- Add a task with a when: clause that checks a fact or variable
- when: uses raw Jinja2 expressions without {{ }} — just write the condition directly
- The task will be skipped with "skipping" status if the condition is false
cat >> handler-demo.yml << 'EOF'
- name: Alpine-only task
debug:
msg: "This host runs Alpine Linux"
when: ansible_os_family == "Alpine"
- name: Skip on Alpine
debug:
msg: "This would run on non-Alpine hosts"
when: ansible_os_family != "Alpine"
EOF 💡 Common conditions: ansible_os_family == "Debian", inventory_hostname == "web1", my_var is defined, my_list | length > 0.
○ Register command output
- Use register: to capture the result of a task into a variable
- The registered variable contains stdout, stderr, rc (return code), and more
- Add a debug task to inspect the registered variable and see its structure
cat > register-demo.yml << 'EOF'
---
- name: Register demo
hosts: target
tasks:
- name: Check disk usage
command: df -h /
register: disk_result
- name: Show disk output
debug:
var: disk_result.stdout_lines
EOF
ansible-playbook register-demo.yml 💡 Registered variables have these keys: .stdout, .stdout_lines (as list), .stderr, .rc, .changed, .failed. Use debug: var: to inspect them.
○ Use a registered variable in a conditional
- Combine register: and when: to make decisions based on command output
- For example, check if a file exists and only create it if missing
- This pattern replaces complex shell scripting with clean, readable Ansible logic
cat > conditional-demo.yml << 'EOF'
---
- name: Conditional with register
hosts: target
tasks:
- name: Check if /tmp/marker exists
stat:
path: /tmp/marker
register: marker_check
- name: Create marker if missing
copy:
content: "Created by Ansible\n"
dest: /tmp/marker
when: not marker_check.stat.exists
- name: Report marker status
debug:
msg: "Marker already existed, skipping creation"
when: marker_check.stat.exists
EOF
ansible-playbook conditional-demo.yml 💡 The stat module returns .stat.exists, .stat.isdir, .stat.size, and more. It is the idiomatic way to check file state in Ansible.
Expected:
First run: "Create marker" is changed. Second run: "Create marker" is skipped, "Report marker status" fires.
Structure your automation with roles
○ Create a role skeleton
- Run ansible-galaxy init to scaffold a standard role directory structure
- This creates directories for tasks, handlers, templates, files, vars, defaults, and meta
- Explore the created structure with ls -la roles/webserver/ to see what was generated
ansible-galaxy init --init-path=roles webserver && ls -la roles/webserver/ 💡 The role directory names are conventions Ansible auto-discovers: tasks/main.yml runs automatically, defaults/main.yml provides default variables, etc.
○ Define role tasks
- Edit roles/webserver/tasks/main.yml to add tasks for the role
- Tasks in a role do not need the play-level boilerplate (hosts:, become:) — they are just a list of tasks
- Each task file starts with --- and a list of task definitions
cat > roles/webserver/tasks/main.yml << 'EOF'
---
- name: Install nginx
apk:
name: nginx
state: present
- name: Create web root
file:
path: "{{ web_root }}"
state: directory
mode: "0755"
- name: Deploy index page
template:
src: index.html.j2
dest: "{{ web_root }}/index.html"
notify: Restart nginx
EOF 💡 Role tasks can reference variables from defaults/ or vars/, and templates from the role templates/ directory without full paths.
○ Add default variables
- Edit roles/webserver/defaults/main.yml to define variables with sensible defaults
- Defaults have the lowest precedence — they can be overridden by vars:, group_vars, or extra-vars
- This makes your role flexible and reusable across different environments
cat > roles/webserver/defaults/main.yml << 'EOF'
---
web_root: /var/www/html
nginx_port: 80
site_title: "Ansible Lab"
EOF 💡 Variable precedence (low to high): role defaults -> inventory vars -> playbook vars -> extra vars (-e). Defaults are meant to be overridden.
○ Create a playbook that uses the role
- Create site.yml with a roles: section that references your webserver role
- Add a template file at roles/webserver/templates/index.html.j2 for the role to deploy
- Also add a handler in roles/webserver/handlers/main.yml for the restart notification
cat > roles/webserver/templates/index.html.j2 << 'EOF'
<html><body><h1>{{ site_title }}</h1><p>Served from {{ ansible_hostname }}</p></body></html>
EOF
cat > roles/webserver/handlers/main.yml << 'EOF'
---
- name: Restart nginx
service:
name: nginx
state: restarted
EOF
cat > site.yml << 'EOF'
---
- name: Deploy webserver
hosts: target
become: yes
roles:
- webserver
EOF 💡 You can override role defaults in the playbook: roles: - { role: webserver, nginx_port: 8080 }. Or use vars: at the play level.
○ Run the role-based playbook
- Execute site.yml — Ansible automatically finds and runs tasks, handlers, and templates from the role
- Verify the index page was deployed by fetching it from the target
- Notice how the playbook is clean and short — all complexity lives in the role
ansible-playbook site.yml && ansible target -m command -a "cat /var/www/html/index.html" 💡 Roles promote reuse. You can share roles via Ansible Galaxy (ansible-galaxy install) or keep a local roles/ directory in your project.
Expected:
The HTML file on the target contains the rendered site_title and hostname from the template.
Coordinate complex deployments across multiple hosts
○ Write a multi-play playbook
- Create a playbook with two separate plays, each with its own hosts: directive
- The first play targets localhost (the control node) for preparation tasks
- The second play targets the target group for deployment — plays run sequentially
cat > orchestrate.yml << 'EOF'
---
- name: Prepare on control node
hosts: localhost
connection: local
tasks:
- name: Generate deployment timestamp
command: date +%Y%m%d-%H%M%S
register: deploy_timestamp
- name: Create deployment manifest
copy:
content: "deploy_id: {{ deploy_timestamp.stdout }}\n"
dest: /tmp/deploy-manifest.yml
- name: Deploy to targets
hosts: target
become: yes
tasks:
- name: Show deployment start
debug:
msg: "Starting deployment on {{ inventory_hostname }}"
- name: Ensure app directory exists
file:
path: /opt/myapp
state: directory
mode: "0755"
EOF 💡 Each play is a separate YAML document in the list. Variables registered in one play are NOT available in another — use set_fact with cacheable: yes or a shared file.
○ Use serial for rolling deploys
- Add serial: to a play to limit how many hosts are updated at once
- serial: 1 updates one host at a time, serial: "50%" updates half the group
- This prevents taking down all servers simultaneously during a deployment
cat > rolling.yml << 'EOF'
---
- name: Rolling deployment
hosts: target
become: yes
serial: 1
tasks:
- name: Deploy application update
copy:
content: "version: 2.0\n"
dest: /opt/myapp/version.txt
- name: Verify deployment
command: cat /opt/myapp/version.txt
register: version_check
- name: Confirm version
assert:
that:
- "'2.0' in version_check.stdout"
fail_msg: "Deployment verification failed!"
EOF
ansible-playbook rolling.yml 💡 serial: can also be a list like [1, 5, "100%"] to start cautiously and ramp up. Combine with max_fail_percentage: to abort on too many failures.
○ Delegate tasks to another host
- Use delegate_to: to run a task on a different host than the play targets
- Common use: update a load balancer from a webserver play, or write to a central log
- The task runs on the delegated host but the inventory_hostname variable still refers to the original target
cat > delegate.yml << 'EOF'
---
- name: Delegation demo
hosts: target
tasks:
- name: Record deployment on control node
copy:
content: "{{ inventory_hostname }} deployed at {{ ansible_date_time.iso8601 }}\n"
dest: "/tmp/deploy-log-{{ inventory_hostname }}.txt"
delegate_to: localhost
- name: Run actual task on target
command: echo "Deployed on {{ inventory_hostname }}"
EOF
ansible-playbook delegate.yml 💡 delegate_to: localhost runs the task on the control node. Use delegate_facts: true if you want gathered facts to be assigned to the delegated host instead.
○ Run a task only once with run_once
- Add run_once: true to a task that should execute on only the first host in the group
- This is useful for database migrations, schema updates, or one-time setup tasks
- The task runs on the first host in the batch but its results are available to all hosts
cat > run-once.yml << 'EOF'
---
- name: Run-once demo
hosts: target
tasks:
- name: One-time setup (runs on first host only)
copy:
content: "initialized: true\nsetup_host: {{ inventory_hostname }}\n"
dest: /tmp/cluster-init.txt
delegate_to: localhost
run_once: true
- name: Per-host task
debug:
msg: "Configuring {{ inventory_hostname }}"
EOF
ansible-playbook run-once.yml 💡 run_once is often combined with delegate_to for tasks like "register this deployment in a central database". It defaults to running on the first host in the play.
○ Chain playbooks with import_playbook
- Create a master playbook that imports other playbooks in sequence
- import_playbook is a top-level directive — it goes at the play list level, not inside a play
- This lets you compose complex workflows from smaller, testable playbook files
cat > master.yml << 'EOF'
---
- import_playbook: orchestrate.yml
- import_playbook: rolling.yml
- name: Final verification
hosts: target
tasks:
- name: Confirm everything is deployed
command: ls -la /opt/myapp/
register: final_check
- name: Show results
debug:
var: final_check.stdout_lines
EOF
ansible-playbook master.yml 💡 import_playbook is static (parsed at load time). There is no dynamic include_playbook. For conditional inclusion, use include_role or include_tasks within a play.
Expected:
All three playbooks run in sequence: orchestrate, then rolling, then the final verification play.
Manage secrets securely in your automation
○ Create an encrypted vault file
- Use ansible-vault create to make a new encrypted file — it will prompt for a vault password
- For this lab, use a simple password like "labpass" since this is a practice environment
- The file is encrypted with AES-256 and safe to commit to version control
echo "labpass" > /tmp/.vault-pass && ansible-vault create --vault-password-file=/tmp/.vault-pass secrets.yml 💡 In production, use --vault-password-file pointing to a file outside your repo, or use --ask-vault-pass to type it interactively. Never commit the password file.
○ Add sensitive variables to the vault
- Use ansible-vault edit to open the encrypted file, or create it with content directly
- Store database passwords, API keys, tokens, and other secrets as YAML variables
- The file looks like normal YAML when decrypted but is AES-256 encrypted on disk
cat > secrets-plain.yml << 'EOF'
---
db_password: "s3cret_P@ssw0rd"
api_key: "ak_live_12345abcde"
app_secret: "super-secret-token-here"
EOF
ansible-vault encrypt --vault-password-file=/tmp/.vault-pass secrets-plain.yml
cat secrets-plain.yml 💡 After encryption, the file content starts with $ANSIBLE_VAULT;1.1;AES256 followed by hex-encoded ciphertext. The original YAML is gone from disk.
Expected:
The cat output shows encrypted content starting with $ANSIBLE_VAULT;1.1;AES256, not the original YAML.
○ Reference vault variables in a playbook
- Use vars_files: in your playbook to include the encrypted vault file
- Reference the vault variables like any other variable with {{ variable_name }}
- Ansible decrypts the vault at runtime and makes variables available seamlessly
cat > secure-deploy.yml << 'EOF'
---
- name: Deploy with secrets
hosts: target
become: yes
vars_files:
- secrets-plain.yml
tasks:
- name: Deploy app config with secrets
copy:
content: |
[database]
password = {{ db_password }}
[api]
key = {{ api_key }}
dest: /tmp/app-secrets.conf
mode: "0600"
- name: Verify secret file permissions
file:
path: /tmp/app-secrets.conf
mode: "0600"
EOF 💡 Set mode: "0600" on secret files so only the owner can read them. Use no_log: true on tasks that handle secrets to prevent them from appearing in Ansible output.
○ Run the playbook with vault decryption
- Execute the playbook with --vault-password-file to provide the decryption key
- Alternatively, use --ask-vault-pass to be prompted interactively
- Ansible decrypts vault files in memory only — they are never written to disk in plaintext
ansible-playbook secure-deploy.yml --vault-password-file=/tmp/.vault-pass 💡 You can set ANSIBLE_VAULT_PASSWORD_FILE in your environment or ansible.cfg to avoid passing --vault-password-file every time.
Expected:
Playbook runs successfully, deploying the config with decrypted secrets to the target.
○ Encrypt an existing file in place
- Use ansible-vault encrypt to encrypt a plaintext YAML file in place
- Use ansible-vault view to see the decrypted contents without editing
- Use ansible-vault decrypt to permanently remove encryption (be careful in repos)
cat > extra-vars.yml << 'EOF'
---
backup_key: "backup-encryption-key-2026"
monitoring_token: "mon_tok_abcdef"
EOF
ansible-vault encrypt --vault-password-file=/tmp/.vault-pass extra-vars.yml && echo "--- Encrypted content ---" && head -3 extra-vars.yml && echo "--- Decrypted view ---" && ansible-vault view --vault-password-file=/tmp/.vault-pass extra-vars.yml 💡 Best practice: use ansible-vault encrypt_string to encrypt individual values inline rather than whole files. This lets you mix encrypted and unencrypted vars in one file.
Expected:
The encrypted file shows $ANSIBLE_VAULT header, then ansible-vault view shows the original YAML content.
What You Can Do
- Control node with Ansible pre-installed
- Target node accessible via SSH (pre-configured keys)
- Full playbook execution environment
- Jinja2 templates, roles, and handlers
- Ansible Vault for secret management
- Alpine Linux with apk package manager on target
Learning Objectives
Beginner
- Run ad-hoc commands
- Understand inventory files
- Ping and gather facts
Intermediate
- Write and execute playbooks
- Use variables and templates
- Deploy configuration files
Advanced
- Create roles
- Use handlers and conditionals
- Register and use variables
Expert
- Multi-play orchestration
- Ansible Vault secrets
- Dynamic inventory and delegation
Key Commands
ansible --versionCheck Ansibleansible target -m pingPing targetansible-playbookRun playbookansible-playbook --checkDry runansible target -m setupGather facts LIVE Connecting...
LIVE Connecting...
Session
--- Time Left --:--
CPU 0%
MEM 0%
📝 Code Editor Mode — launch the lab above for a real Ansible environment
Editor
Validation & Plan
📝
Select a tool and click "Validate" to see the output
Quick Reference
resourceDefine infrastructure resourcesproviderConfigure cloud/service providersvariableDefine input variablesoutputDefine output valuesmoduleReusable configuration groupsdataQuery existing resourcesIaC Best Practices
🔒 Version Control
Store all infrastructure code in Git. Track changes, review PRs, and maintain history.
📦 Modularity
Break configurations into reusable modules. DRY (Don't Repeat Yourself) applies to infrastructure too.
🧪 Testing
Validate configurations before applying. Use plan/dry-run modes to preview changes.
🔐 Secrets Management
Never commit secrets. Use vault solutions, environment variables, or encrypted backends.