Server Deployment and Configuration Questions

Focuses on provisioning and performing the initial configuration of servers, whether physical or virtual. Skills assessed include operating system installation and hardening, network interface and IP configuration, DNS and domain joining, user and permission setup, baseline security and patching, installation of required runtime components and monitoring agents, backup setup, and initial performance tuning. Also covers imaging and provisioning strategies, automation and scripting for unattended installs, virtualization and cloud instance initialization, and validation steps to confirm a server is production ready.

MediumTechnical

30 practiced

Design a reasonable secure baseline for a Linux server to be applied immediately after provisioning. Include SSH hardening, account and sudo policies, minimal services, file permissions, audit/logging settings, kernel parameter tweaks, and a simple patch policy. Explain why each item is important and how to automate enforcement.

Sample Answer

**Baseline summary (applied immediately after provisioning)**

**1) SSH hardening**- Enforce Protocol 2, disable root login, use key auth only, limit ciphers/MACs, change default port optionally, enable IdleTimeout.- Why: prevents password brute-force and limits attack surface.- Automation: Ansible role to deploy /etc/ssh/sshd_config and restart sshd; cloud-init for first-boot key injection.

**2) Account & sudo policies**- Create non-root admin group (wheel/sudo), disable direct root SSH, enforce password complexity & max reuse via pam_pwquality, set sudo to require auth and log via Defaults logfile=/var/log/sudo.log.- Why: least privilege and accountability.- Automation: Manage /etc/sudoers.d and PAM via Ansible; use LDAP/AD or SSSD for central auth.

**3) Minimal services**- Disable/remove unused daemons (telnet, ftp, rpcbind, avahi). Use systemctl mask/disable.- Why: fewer services = fewer vulnerabilities.- Automation: Inventory with Ansible/systemd templates; apply disable list.

**4) File permissions**- Enforce /etc/ssh ownership and perms, /etc/shadow 640 root:shadow, home dirs 750.- Why: prevents info disclosure.- Automation: Ansible tasks with file module and a remediation playbook.

**5) Audit & logging**- Enable auditd rules for execs, auth, sudo, network changes; forward logs to central SIEM (rsyslog/Fluentd).- Why: detects intrusion and provides forensics.- Automation: Deploy audit.rules and rsyslog config with Ansible; use ossec/wazuh agents.

**6) Kernel tweaks**- Harden network (disable ipv6 if unused, disable ip_forward, enable rp_filter, tighten net.ipv4.conf.* settings), enable ASLR, cgroup hardening.- Why: reduces kernel-level attack vectors.- Automation: sysctl.d files via Ansible and sysctl --system; use CIS benchmark scripts.

**7) Patch policy**- Apply critical security updates within 24h, regular weekly patch window for other updates; enable unattended-upgrades for security only on non-production.- Why: timely patching reduces exploit window.- Automation: configure unattended-upgrades, apt/yum-cron for baseline; orchestration via Ansible/Cron + patch reporting.

**Enforcement & Compliance**- Use a configuration management system (Ansible / Salt / Puppet), CIS benchmark scanning (OpenSCAP, Lynis), and remediation playbooks run in CI or on-boot.- Maintain idempotent playbooks, automated tests (molecule), and centralized reporting for drift detection.

This baseline balances immediate risk reduction with automation to ensure consistent, auditable, and maintainable server hardening.

EasyTechnical

24 practiced

Explain the essential steps you perform when provisioning a new Linux server (Ubuntu or CentOS) for production use. Cover partitioning and filesystem layout decisions, creating administrative users and placing SSH keys, disabling password authentication, configuring a basic firewall (ufw/iptables/nft), enabling automatic security updates or patching, installing monitoring and backup agents, and a short validation checklist to confirm the server is reachable and minimally secure.

Sample Answer

**Overview / approach**I follow a repeatable checklist: secure bootstrapping, minimal packages, SSH hardening, firewall, patching, monitoring/backup, then validate.

**Partitioning & filesystem**- Prefer LVM or separate partitions: /boot (512M), / (20–50G), /var (separate for logs), /home (optional), /srv (app data), swap (size per RAM).- Use ext4 or xfs (XFS for large filesystems). Use LVM for snapshots and resizing.

**Admin users & SSH**- Create admin user, add to sudoers:

bash

adduser deployer
usermod -aG sudo deployer

- Place public key in /home/deployer/.ssh/authorized_keys (600/700 perms).

**Disable password auth**- Edit /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no; then systemctl restart sshd.

**Firewall**- Simple UFW example:

bash

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp
ufw enable

- For iptables/nftables, apply equivalent stateful rules and persist them.

**Automatic updates**- Ubuntu: install unattended-upgrades and enable security updates.- CentOS/RHEL: enable dnf-automatic or yum-cron; test in apply mode.

**Monitoring & backups**- Install node_exporter/Datadog/Prometheus agent and configure alerting.- Install backup agent (Borg/Restic or vendor agent), register, and run initial backup; verify restore.

**Validation checklist**- SSH access with key as admin; root login disabled.- Ports: only expected ports open (nmap/ss).- Updates: security updates enabled and recent patch applied.- Monitoring heartbeat visible; backup completed and test restore passes.- Disk layout and permissions checked (lsblk, df -h, mount).- Logs: no critical errors in journalctl -p err.

HardTechnical

31 practiced

As a senior Systems Administrator, you must lead a cross-functional team to migrate from manual server provisioning to an Infrastructure-as-Code pipeline. Outline your leadership approach: goals, roadmap, stakeholders, risk mitigation, training plan, and metrics to track adoption and success. Describe how you would handle resistance from teams comfortable with manual processes.

Sample Answer

**Situation & Goal** I led a program to replace manual server builds with an IaC pipeline so provisioning is repeatable, auditable, and ≤30 minutes end-to-end. Primary goals: reduce configuration drift, shorten time-to-provision by 80%, enable self-service, and improve security posture.

**Roadmap (phased)** - Discovery (2 wks): inventory, dependencies, compliance needs. - Pilot (6 wks): author Terraform modules + Packer images for non-prod; CI/CD with GitLab; validate rollback. - Expand (8–12 wks): add prod patterns, service catalog, RBAC, secrets integration. - Handoff (4 wks): ops runbooks, automated tests, and deprecation plan for manual scripts.

**Stakeholders** - Platform engineers (owners of CI/CD) - App teams (consumers) - Security & Compliance (policy gates) - Change & Support (operations runbooks) I run weekly syncs and a steering sync biweekly for blockers and approvals.

**Risk Mitigation** - Start in non-prod; maintain blue/green rollback patterns. - Automated tests (unit for modules, integration in sandbox). - Incremental cutovers and feature flags. - Backup/restore validation before each migration wave.

**Training & Adoption** - Hands-on workshops + lab exercises per team. - “Shadow provisioning” rotations pairing senior admins with app owners. - Quickstart templates and a central docs site. - Office hours + Slack channel for 90 days.

**Metrics** - Time to provision (baseline vs after) - Number of manual builds per month (trend to 0) - Drift incidents and MTTR - Rate of IaC usage (percentage of new servers via pipeline) - Number of rollbacks/failures in pipeline

**Handling Resistance** Acknowledge concerns, show quick wins from pilot, invite skeptics into the pilot so they influence design, preserve a manual path during transition, and measure improvements that matter to them (fewer outages, faster fixes). If a team still resists, I use data, risk assessments, and executive-aligned deadlines to drive adoption while offering targeted support.

EasyTechnical

43 practiced

Write a cloud-init user-data YAML snippet for an Ubuntu instance that creates a user named 'deploy', uploads a provided SSH public key, updates apt package lists, installs nginx and a monitoring agent, and ensures the nginx service is started. Provide a clear, minimal cloud-init example in YAML.

Sample Answer

**Approach**- Create a user "deploy" with sudo and an SSH public key.- Ensure apt lists are updated and required packages installed.- Start and enable nginx; install a monitoring agent (example: datadog-agent placeholder).- Keep the snippet minimal and ready to paste as cloud-init user-data.

**cloud-init user-data (YAML)**

yaml

#cloud-config
users:
  - name: deploy
    gecos: Deploy User
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_authorized_keys:
      - "ssh-rsa AAAA...your-public-key... user@example.com"

package_update: true
packages:
  - nginx
  - curl
  - apt-transport-https

runcmd:
  - [ sh, -c, "systemctl enable --now nginx" ]
  - [ sh, -c, "echo 'Installing monitoring agent (example)'; curl -sS https://example.com/install-agent.sh | bash" ]

Notes:- Replace the SSH key and monitoring-agent install command/URL with your actual public key and vendor instructions (e.g., Datadog, Prometheus node-exporter).- For production, pin package versions or add apt repositories and GPG keys securely.

HardSystem Design

33 practiced

Propose a rolling-image update strategy for tens of thousands of stateless servers that minimizes customer impact. Explain how to build images, stagger rollouts, detect failures, and roll back bad images. Include considerations for immutable infrastructure, canary percentages, traffic shifting, and monitoring gates.

Sample Answer

**Overview**I’d use immutable images + automated canary rollouts with traffic-shifting and monitoring gates so updates to tens of thousands of stateless servers are safe, observable, and fast to rollback.

**Image build & validation**- Build images in CI (packer/container builder) that embed versioned artifacts, bootstrap scripts, and immutable config references.- Run unit tests, integration tests, and smoke-start validation inside staging images. Produce signed artifact with metadata (git commit, build ID, checksum).

**Staggered rollout strategy**- Canary phases by percentage: 0.5% → 1% → 5% → 25% → 100%. For 50k servers: 250 → 500 → 2.5k → 12.5k → full.- Use orchestration (Terraform/Cloud API/cluster autoscaler) to replace instances in small batches; create new instances with new image and shift traffic gradually.

**Traffic shifting & routing**- Use load balancer weights / service mesh (Envoy/Istio) to control percentage of user traffic to new instances independent of instance count.- Start traffic at 0% to canaries (health checks only), then incrementally increase weight per phase.

**Monitoring gates & failure detection**- Gate on SLOs: error rate, latency P95/P99, CPU, memory, request success ratio, business KPIs (checkout rate).- Use automated monitors and anomaly detection (prometheus + alertmanager, synthetic transactions). Define thresholds per metric and require stability for N minutes before progressing.- Include readiness and liveness checks, and perform end-to-end synthetic tests.

**Rollback and remediation**- If any gate breaches: immediately stop rollout, shift traffic away from new image, and trigger automated rollback: deregister new instances and re-create previous image or re-weight LB to old pool.- Keep previous image immutable and ready in registry for fast redeploy.- Capture detailed logs/traces (correlate by build ID) to triage.

**Operational considerations**- Conservatively size canary pools for stateful-dependent dependencies (DB load).- Use feature flags for risky behavior inside otherwise safe images.- Run dry-run deployments and disaster-recovery rehearsals.- Audit and document every rollout (who, build ID, metrics snapshot).

This approach minimizes customer impact via small canaries, observability gates, immutable artifacts, automated rollback, and controlled traffic shifting.

Unlock Full Question Bank

Get access to hundreds of Server Deployment and Configuration interview questions and detailed answers.

Join thousands of developers preparing for their dream job.