Scripting and Automation — Flashcards

Automation executes tasks without requiring human presence, running as fast as the underlying hardware, without typos or fatigue. Primary purposes: (1) Eliminate repetitive manual work — tasks run 24/7 without human intervention. (2) Improve accuracy — no typing errors, consistent execution every time. (3) Increase reaction speed — scripts respond in milliseconds vs. minutes for human operators. (4) Enforce consistency — every system receives the same configuration. (5) Free skilled staff — analysts focus on analysis rather than repetitive administration.

Security baseline enforcement: automation continuously verifies that systems comply with defined security standards and corrects deviations without human intervention. Examples: (1) A script monitors for new patches and deploys them automatically when they appear in a designated folder — every system patched, no manual steps. (2) A script checks firewall rules on every deployed device and adds any missing rules automatically. (3) A script compares running server configurations against a known-good baseline and corrects any drift. Without automation, baseline drift is inevitable because manual processes are inconsistent.

Secure scaling: ensuring security controls expand automatically when cloud infrastructure scales. Without automation: when a new server is added, security groups, firewall rules, and encryption must be configured manually — and are frequently missed. With automation: a provisioning script that creates the server also configures all required security controls as part of the same workflow. Security is intrinsic to provisioning, not a subsequent manual step. As cloud environments scale dynamically (adding dozens of instances in seconds), manual security configuration cannot keep pace. Automation is the only feasible approach at cloud scale.

Workforce multiplier: automation effectively multiplies the capacity of the security team by operating 24/7 and handling many tasks simultaneously without additional headcount. A small team with comprehensive automation covers the equivalent workload of a much larger manual team. Scripts handle monitoring, alerting, patching, provisioning, and remediation continuously — not just during business hours. This allows skilled analysts to focus on work that requires human judgment (threat hunting, incident investigation, architecture) rather than repetitive administration. Complementary concept: employee retention — automation reduces boring work, improving job satisfaction and keeping skilled staff engaged.

Provisioning automation: when a new employee is hired, a script creates their account, assigns group memberships, creates directories, grants access to required resources (email, printers, shared drives), and configures their workstation — all triggered automatically from an HR system event. No manual steps. Deprovisioning automation is security-critical: when an employee leaves, automation immediately disables their account, removes all group memberships, and revokes application access. Manual offboarding frequently leaves accounts active for days or weeks after departure, creating insider threat risk. Automation eliminates this lag — access is revoked the moment the HR trigger fires, not when IT gets around to it.

Guard rails: automated validation systems that intercept and verify proposed actions before they execute, blocking operations that would cause harm regardless of whether the operator has permission. Example: a technician with full delete permissions selects the wrong directory for deletion — a guard rail detects that the selected path contains critical system files and blocks the operation before any files are removed. Difference from access controls: access controls determine WHO can perform an action (authentication/authorization). Guard rails determine WHETHER a specific instance of an action is safe (operational safety). An authorized user can be stopped by a guard rail; an unauthorized user is stopped by access control.

Escalation automation: scripts attempt automated remediation first; only if automation fails does a human administrator get paged. Example workflow: (1) Monitoring detects a failed service. (2) Script attempts to restart the service automatically. (3) If restart succeeds — no alert generated, no human involved. (4) If restart fails after two attempts — incident ticket created, on-call technician paged. Problem solved: alert fatigue. If every monitoring event immediately pages a human, operators begin ignoring alerts. Escalation automation ensures human attention is reserved for problems that scripts cannot resolve on their own, making alerts meaningful. Combined benefit: ticket creation is automatic, so the ticket already exists with diagnostic data before the technician reads the page.

CI/CD: Continuous Integration / Continuous Deployment — automated pipelines that build, test, and deploy code changes continuously rather than in infrequent manual releases. Security integration points in CI/CD pipelines: (1) Static application security testing (SAST) — code is automatically scanned for vulnerabilities before merging. (2) Dependency vulnerability scanning — third-party libraries checked against known CVE databases. (3) Container image scanning — base images verified to be free of known vulnerabilities. (4) Compliance checks — infrastructure-as-code validated against security policy before deployment. Code that fails security gates cannot reach production without explicit human override, embedding security automatically into every release cycle.

API integration: automation scripts use Application Programming Interfaces (APIs) to communicate with and control infrastructure devices and cloud services programmatically, without a human logging into a UI. APIs expose functions of firewalls, routers, cloud platforms, identity systems, and security appliances that scripts can call directly. What this enables: (1) Automatic firewall rule updates when new threat intelligence arrives. (2) Dynamic cloud resource provisioning triggered by demand. (3) Security policy enforcement across multi-cloud environments from a single automation script. (4) Orchestration of multiple different systems in a coordinated workflow. APIs allow different technologies to "speak the same language" — a key phrase for the exam.

Technical debt: the accumulation of deferred work created when automation patches symptoms rather than fixing root causes. Example: a server constantly runs low on disk space. A script clears temporary files whenever space drops below 10%, keeping the server running. The underlying cause (why so much temporary data?) is never investigated. The technical debt is the unresolved root problem growing behind the automated workaround. Danger: debt compounds — the underlying problem grows while the script masks it. Eventually, the problem becomes too large for the script to contain, and resolving the accumulated technical debt becomes far more expensive than fixing the root cause would have been originally. The exam tests recognizing this as a risk of automation.

Single point of failure: when automation replaces a manual process, a failure in the automation simultaneously disables everything that depends on it. Example: a provisioning script is the only mechanism for creating user accounts. The script fails (API change, OS update, bug). Result: all new user account creation stops until the script is repaired. The automation that was meant to improve reliability created a failure mode that would not have existed with manual processes (a human can always create an account manually). Mitigations: redundancy for critical automation systems; monitoring of the monitors (scripts that verify automation is running correctly); documented fallback manual procedures; avoid single-script dependencies for critical functions.

Ongoing supportability: the challenge that scripts working perfectly today may fail in the future as the environments they manage evolve. Causes of future failure: (1) OS updates — commands, file paths, or behavior changes between OS versions. (2) API modifications — cloud providers and applications change API schemas; scripts calling deprecated endpoints break. (3) Scripting language updates — Python, PowerShell, Bash syntax changes between major versions. (4) Infrastructure changes — network topology, device models, or authentication methods change. Mitigation: version control for all scripts, documentation of dependencies, ownership assignment (named individual responsible for maintaining each script), and periodic review cycles to test scripts against current infrastructure.