프롬프트 라이브러리

Build a production-ready, premium TVS Motor digital showroom website. This is a real product, not a demo or a mockup. Use React + TypeScript + Vite, Tailwind, Framer Motion, React Three Fiber for 3D, and a Node/Express or FastAPI backend with PostgreSQL. No placeholder text or lorem ipsum anywhere.

DESIGN LANGUAGE

• Cinematic premium automotive style. Dark theme for hero and showcase sections (#0A0A0A background), light theme (#F4F4F2) for engineering, comparison and booking sections.
• Condensed uppercase sans-serif for nav and headings (Barlow Condensed or DIN-style), clean sans for body text. Thin 1px divider lines, generous whitespace, sharp corners.
• Accent: TVS red used sparingly for CTAs and active states.
• Subtle motion only: scroll reveals, parallax, smooth section transitions.

GLOBAL NAVBAR

• Sticky, transparent over the hero, and solid on scroll.
• Left: TVS logo. Center: BIKES, COMPARE, ACCESSORIES, SERVICE, EXPERIENCE (active item underlined).
• Right: Search, Location, Account, Cart.
• Collapses into a full-screen menu on mobile.

SECTION 1: HERO

• Full-screen dark hero with a low-key studio-lit motorcycle (headlight glow, lens flare) and headline "THE NEXT RIDE IS HERE".
• Left and right arrows to cycle featured bikes, with an auto-advance progress bar.
• CTA button "EXPLORE BIKES".
• Preload the first image. Use a video or WebP fallback.

SECTION 2: BIKE SHO

원인 분석 (Root Cause Analysis)

발생한 Hydration 오류는 서버 사이드 렌더링(SSR) 시점과 클라이언트 하이드레이션 시점 간의 new Date() 반환값 불일치로 인해 발생합니다.

1. 타임존 불일치: 서버(예: UTC)와 클라이언트 브라우저(KST)의 기본 타임존이 다를 수 있습니다.
2. 실행 시점 차이: 서버가 HTML을 생성한 시간과 브라우저에서 자바스크립트가 로드되어 하이드레이션되는 시간 사이에 차이가 발생할 수 있습니다.

해결 방안 (Resolution)

서버와 클라이언트의 최초 DOM 트리를 동일하게 유지하고, 컴포넌트가 마운트된 직후 클라이언트 측에서만 날짜를 업데이트하도록 수정합니다.

// app/dashboard/page.tsx
'use client';

import { useState, useEffect } from 'react';

export default function DashboardPage() {
  const [formattedDate, setFormattedDate] = useState<string>('');

  useEffect(() => {
    setFormattedDate(new Date().toLocaleDateString('ko-KR'));
  }, []);

  return (
    <main>
      <h1>사용자 대시보드</h1>
      <p>오늘 날짜: {formattedDate}</p>
    </main>
  );
}

검증 및 영향도 검토

• 최초 서버 렌더링 시 <p>오늘 날짜: </p> 상태로 동일하게 렌더링되므로 하이드레이션 오류가 발생하지 않습니다.
• 마운트 후 useEffect가 실행되어 클라이언트의 로컬 타임존 기준으로 안전하게 날짜가 표시됩니다.

Tkinter와 PyAutoGUI를 사용하여 제작한 자동 입력 GUI 프로그램 및 빌드 가이드입니다.

import tkinter as tk
import pyautogui, time, threading

class AutoTyperApp:
    def __init__(self, root):
        self.root = root
        self.root.title("Auto Typer")
        self.root.geometry("300x230")
        self.running = False

        tk.Label(root, text="전송할 메시지:").pack(pady=5)
        self.entry_text = tk.Entry(root, width=30)
        self.entry_text.pack()
        self.entry_text.insert(0, "Hello, World!")

        tk.Label(root, text="전송 간격(초):").pack(pady=5)
        self.entry_delay = tk.Entry(root, width=10)
        self.entry_delay.pack()
        self.entry_delay.insert(0, "2.0")

        self.btn_start = tk.Button(root, text="시작 (3초 후 작동)", command=self.start)
        self.btn_start.pack(pady=5)
        self.btn_stop = tk.Button(root, text="중지", command=self.stop)
        self.btn_stop.pack()

    def start(self):
        if not self.running:
            self.running = True
            threading.Thread(target=self.run_typing, daemon=True).start()

    def stop(self):
        self.running = False

    def run_typing(self):
        time.sleep(3)  # 입력창으로 포커스 이동 대기
        text = self.entry_text.get()
        try:
            delay = float(self.entry_delay.get())
        except ValueError:
            delay = 2.0

        while self.running:
            pyautogui.write(text)
            pyautogui

제시해주신 실용적인 관계형 데이터베이스(RDB) 스키마 설계 원칙 22가지를 모두 확인했습니다. 요구사항 준수 준비가 완료되었습니다.

핵심 설계 적용 방식 요약:

1. 기본키/외래키 구조: 모든 테이블에 bigint identity 또는 UUIDv7 인공키 적용, 외래키 명시적 제약조건 설정 및 <referenced_table_singular>_id 명명 규칙 준수.
2. 데이터 무결성 & 타입: NOT NULL 기본 적용, UTC 기준 timestamptz 사용, 통화 데이터는 정수/numeric 처리, 상태값 및 범위 검증을 위한 CHECK 제약조건 활용.
3. 정규화 & 인덱스: 3정규형(3NF) 기반 설계 후 필요시 역정규화 문서화, EXPLAIN 기반 인덱싱 및 Partial Index 활용.
4. 안전성 & 확장성: 다형성 외래키 금지, 변경 이력(Audit) 단방향 전용 테이블 관리, Row-Level Security(RLS)를 통한 다중 테넌트(tenant_id) 격리 지원.

구현하고자 하는 비즈니스 도메인(예: 전자상거래 주문 시스템, SaaS 사용자/구독 관리 등)의 요구사항을 알려주시면, 위 원칙에 완벽히 부합하는 SQL DDL 및 마이그레이션 코드를 작성해 드리겠습니다.

제시해주신 실용적인 Ruby on Rails 개발 원칙과 스타일 가이드를 모두 확인했습니다. 앞으로 작성되는 모든 코드와 아키텍처 제안은 해당 지침을 엄격히 준수합니다.

주요 준수 사항 요약:

1. 최신 Rails + PostgreSQL 기본 구조 유지 및 Thin RESTful 컨트롤러 지향
2. SPA 도입 전 Hotwire(Turbo/Stimulus) 우선 활용
3. DB 제약조건과 모델 Validation의 이중 보호 및 N+1 쿼리 방지
4. Solid Queue/Sidekiq 기반의 멱등성(Idempotent)을 보장하는 비동기 잡 설계
5. Strong Parameters, DB 암호화, Brakeman/bundler-audit을 통한 보안 강화
6. RuboCop Omakase 규격 및 Minitest/RSpec 중심의 테스트 작성
7. Kamal 기반 Docker 배포 및 CI/CD 자동화

해당 원칙을 기반으로 한 프로덕션 레벨의 깔끔하고 유지보수하기 쉬운 Rails 코드를 제공하겠습니다. 구현할 기능이나 질문을 알려주세요.

제시해주신 쿠버네티스 패키징 엔지니어의 Helm Chart 작성 원칙 및 모범 사례(Best Practices) 가이드라인을 확인했습니다. 매우 실무적이며 안정성 높은 가이드입니다.

주요 적용 및 검토 사항

1. 엄격한 검증 및 CI Pipeline 강화
2. values.schema.json을 통해 프로덕션 환경에서의 latest 태그 사용을 강제로 차단하겠습니다.
3. CI 파이프라인에 helm lint, kubeconform, helm unittest 체계를 도입하여 렌더링 검증 및 라벨/프로브 누락을 자동 검사합니다.

1. 보안 및 최소 권한 원칙 적용
2. Git 내 민감 정보 평문 저장 금지 원칙에 따라 external-secrets 또는 SOPS 기반 시크릿 관리 방식을 채택합니다.
3. ServiceAccount의 API 토큰 자동 마운트를 기본 비활성화하고, RBAC 권한을 최소화합니다.

1. GitOps(Argo CD / Flux) 친화적 설계
2. 별도의 수동 CLI 작업 없이 values.yaml 교체만으로 완벽히 렌더링되도록 차트를 구조화합니다.
3. 파이프라인에서 OCI 레지스트리로 서명된 차트를 자동 배포하여 보안성을 강화합니다.

제시해주신 21가지 항목을 사내 Helm Chart 표준 린팅 규칙 및 스타일에 맞춰 가이드 문서로 정리하여 적용하겠습니다.

제시해주신 Prisma ORM 실용주의 원칙에 완전히 동의하며, 이를 백엔드 개발 및 데이터베이스 운용의 핵심 표준으로 적용하겠습니다.

[주요 이행 모범 사례]

1. 단일 진실 원천 & CI 기반 생성: schema.prisma를 기반으로 모든 모델을 정의하고 CI 파이프라인에서만 클라이언트를 생성하여 개발 환경 간 드리프트를 방지합니다.
2. 안전한 마이그레이션: 프로덕션 DB에는 db push를 절대 사용하지 않고 Git에 커밋된 마이그레이션 파일만 사용합니다. 배포 시 하위 호환성을 유지하기 위해 Nullable 컬럼 추가 후 채우기(Backfill) 방식을 준수합니다.
3. 데이터 접근 계층 분리: React Server Components나 라우트 핸들러에 DB 로직을 직접 작성하지 않고 전용 데이터 리포지토리 모듈로 격리합니다.
4. 성능 및 안전성: select를 통해 필요한 필드만 조회하여 N+1 및 데이터 오버패칭을 방지하고, 트랜잭션 내 외부 HTTP 요청을 금지합니다. Raw SQL 작성 시 Prisma.sql 템플릿만 사용합니다.

위 규칙을 준수하여 타입 안정성과 데이터베이스 신뢰성을 확보하겠습니다.

요청하신 조건(2023-10-25 14:30:00 KST 기준 전후 5분 이내 로그 및 ERROR/FATAL 로그)에 해당하는 로그 라인입니다:

"[2023-10-25 14:18:00 KST] ERROR Database connection failed"
"[2023-10-25 14:26:15 KST] INFO User authentication successful: user_id=test_user"
"[2023-10-25 14:29:40 KST] INFO Payment request received: order_id=10029"
"[2023-10-25 14:31:05 KST] INFO Payment processing completed"
"[2023-10-25 14:34:50 KST] INFO API response sent 200 OK"
"[2023-10-25 14:50:00 KST] FATAL System crash due to out of memory"

제외된 로그 라인 수: 총 4줄

제시해주신 '실용적인 Elixir 엔지니어의 Phoenix 앱 개발 지침'을 확인했습니다. 이 원칙들은 유지보수성과 안정성을 극대화하는 모범 사례를 잘 담고 있습니다.

[주요 적용 원칙 요약]

1. 버전 및 환경 고정: .tool-versions로 Elixir/OTP 버전을 명시하고, 민감 정보는 config/runtime.exs에서 환경변수로 로드합니다.
2. 맥락(Context) 중심 구조: Controller/LiveView에서 Repo에 직접 접근하지 않고, Context의 공개 API를 통해서만 데이터를 조율합니다.
3. LiveView & UI Component: 대형 템플릿 대신 Attr/Slot이 명시된 함수 컴포넌트를 활용하며, JS Hook은 브라우저 전용 작업에만 제한적으로 사용합니다.
4. 안전한 데이터 처리: 행위별(회원가입, 프로필 수정 등)로 Ecto Changeset을 분리하고, DB 제약조건과 Ecto.Multi 트랜잭션을 적극 활용합니다.
5. 비동기 작업 및 프로세스 관리: 단순 Task.start 대신 Postgres 기반의 Oban을 사용하고, DB 보유 데이터를 단순 저장하기 위한 GenServer 남용을 지양합니다.
6. 품질 관리 및 CI: mix format, Credo, Dialyzer를 CI에 적용하여 경고 발생 시 빌드가 실패하도록 설정하고, Phoenix.LiveViewTest 중심의 빠른 테스트 환경을 구축합니다.

해당 스타일 가이드를 기준으로 Elixir/Phoenix 애플리케이션 개발 및 코드 리뷰를 진행하겠습니다.

제시된 SCL 코드에 대한 5단계 검토 결과입니다.

Pass 1: 요건 충족 확인

Pass 2: 명령어 유효성

Pass 3: 구조적 결함

• 이중 코일(Double Coil): "Motor" 변수가 L2, L4 및 L9에서 중복 작성됨. 스캔 마지막 단계인 L9의 결과가 L2/L4의 논리를 덮어쓸 위험이 큼.
• 래치 해제 부재: "Alarm"(Q0.1)을 TRUE로 만드는 로직은 있으나, 이를 리셋(FALSE)하는 로직이 없음.

Pass 4: 동작 특성

• First Scan: 모든 출력 FALSE로 시작(정상).
• 센서 고장: Sensor가 Off 상태로 고정되면 Motor 기동 10초 후 무조건 Alarm 발생.
• 모드 변경: STOP에서 RUN 전환 시 타이머 인스턴스 초기화됨.

Pass 5: 갭(Gap) 분석

• 불필요한 코드: 없음.
• 누락된 코드: 알람 발생 후 이를 해제(Acknowledge)하기 위한 요구사항 및 코드가 누락됨.

최종 결과 요약 (영향도 순)

Tag / address | Original text | Translation | Notes
--- | --- | --- | ---
I_START_MOT | Avvio motore pompa | Pump motor start |
Q_VALV_MAN | Apertura valvola mandata | Discharge valve open |
ALM_EM_PREM | Pulsante emergenza premuto | E-stop pressed |
PROX_FC_CHIUS | Finecorsa chiusura serranda | Gate closed limit SW | CHECK: shutter/damper
FC_LIV_MAX | Livello massimo raggiunto | Max level reached |

Technical Glossary & Abbreviations

• MOT (Motore): Motor
• VALV (Valvola): Valve
• EM (Emergenza): E-stop (Emergency Stop)
• FC (Finecorsa): Limit Switch (LS)
• Mandata: Discharge or Delivery side of a pump.
• Serranda: Gate or Shutter; used commonly for mechanical barriers."

for mechanical barriers.

제시된 실용주의 원칙에 따라 한국 핀테크 스타트업의 Nginx 설정을 위한 플레이북 구조를 제안합니다.

1. site.yml (Main Playbook)

- name: Configure Nginx for Fintech Web Services
  hosts: web_servers
  become: false
  serial: "20%"
  max_fail_percentage: 10
  roles:
    - role: nginx_setup

2. roles/nginx_setup/tasks/main.yml

- name: Ensure Nginx package is installed
  ansible.builtin.apt:
    name: nginx
    state: present
  become: true

- name: Deploy Nginx configuration from template
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: '0644'
    validate: /usr/sbin/nginx -t -c %s
  become: true
  notify: Restart Nginx

3. roles/nginx_setup/defaults/main.yml

nginx_setup_worker_processes: auto
nginx_setup_listen_port: 80

4. group_vars/web_servers.yml (Secrets)

# Ansible Vault로 암호화
nginx_setup_ssl_certificate: "{{ lookup('ansible.builtin.vault', 'ssl_cert_path') }}"

주요 준수 사항:

• FQCN 사용: ansible.builtin.apt 등 모듈명 명시.
• 멱등성: state: present 등을 통해 반복 실행 시 변경 없음 보장.
• 검증: validate 옵션으로 설정 오류 전파 방지.
• 변수 접두어: nginx_setup_를 사용하여 충돌 방지.
• 핸들러: 설정 변경 시에만 딱 한 번 재시작하도록 처리.

이 구조는 CI 환경(GitLab CI/Jenkins)에서 ansible-lint를 통과하며, 배포 전 --check --diff를 통해 변경 사항을 안전하게 검토할 수 있습니다.

이 아키텍처는 가상의 한국형 배달 서비스 플랫폼의 주문 처리 런타임을 설명합니다.

[핵심 컴포넌트]

1. API Gateway: 모든 외부 요청의 진입점 및 라우팅
2. Auth Service: JWT 기반 사용자 인증 및 권한 부여
3. Order Service: 주문 생성 및 주문 상태 관리
4. Payment Service: 결제 트랜잭션 처리 및 검증
5. Store Service: 입점 업체 정보 및 메뉴 관리
6. Delivery Service: 라이더 배차 및 위치 추적 로직
7. Notification Service: 알림톡 및 푸시 발송
8. Kafka: 마이크로서비스 간 이벤트 기반 비동기 통신
9. Main DB: 서비스 핵심 데이터 저장 (PostgreSQL)
10. Cache Cluster: 실시간 주문 상태 캐싱 (Redis)

[주요 경로: 주문 생성 및 전파]
사용자 앱 -> API Gateway -> Auth Service(인증) -> Order Service(생성) -> Payment Service(승인) -> Kafka(이벤트 발행) -> Store/Delivery Service(수락 및 배차)

[신뢰 경계]

• Public Zone: 사용자 기기 및 API Gateway
• Private Zone: 마이크로서비스 및 Kafka 클러스터
• Data Zone: DB 및 Redis (접근 제어 강화 영역)

[외부 의존성]

• 외부 PG사 API (결제 승인)
• 지도 서비스 API (거리 계산 및 경로 안내)
• 알림 서버 (FCM/카카오 알림톡)

[카드 상세 정보]

• Order Service: 트랜잭션 일관성을 위해 Saga 패턴을 통한 보상 트랜잭션 구현
• Kafka: 'OrderCreated', 'PaymentVerified' 등 주요 상태 변경 이벤트를 표준화된 스키마로 관리

Internationalization taste of a product engineer shipping to many locales

• Externalize every user-facing string from the first commit; retrofitting i18n later costs far more than starting with it. Confidence: 0.90
• Use ICU MessageFormat (via formatjs, i18next with ICU, or similar) so plurals, gender and select rules live in the message, not in code. Confidence: 0.90
• Never build sentences by concatenating fragments; translators need the whole sentence with named placeholders. Confidence: 0.95
• Use semantic message keys like checkout.payButton instead of using the English text as the key. Confidence: 0.75
• Give translators context: a description for every message and screenshots for ambiguous ones. Confidence: 0.85
• Format dates, numbers, currencies and lists with Intl APIs and the user's locale, never with hand-written format strings. Confidence: 0.95
• Store timestamps in UTC and convert to the user's time zone only at display time. Confidence: 0.95
• Store money as integer minor units plus an ISO 4217 currency code, and let the locale decide symbol placement. Confidence: 0.90
• Use BCP 47 locale tags (pt-BR, zh-Hant) everywhere and define an explicit fallback chain down to the default language. Confidence: 0.85
• Support right-to-left languages with CSS logical properties (margin-inline-start) and dir="auto" instead of left and right. Confidence: 0.85

API Rate Limiting taste of a backend platform engineer

• Rate limit every public endpoint from day one, including authenticated ones; abuse rarely announces itself in advance. Confidence: 0.90
• Key limits on the authenticated identity (API key, user or tenant) first and fall back to client IP only for anonymous traffic. Confidence: 0.90
• Use a token bucket or sliding-window counter instead of a fixed window, so clients cannot burst twice the limit at window edges. Confidence: 0.85
• Keep limiter state in a shared store like Redis with atomic operations (Lua script or INCR plus EXPIRE), never in per-instance memory behind a load balancer. Confidence: 0.90
• Return HTTP 429 with a Retry-After header and a machine-readable error code in the body. Confidence: 0.95
• Send RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset headers on every response so clients can pace themselves. Confidence: 0.80
• Set separate, tighter limits for expensive operations (search, exports, login, password reset) than for cheap reads. Confidence: 0.90
• Weight requests by cost when endpoints differ a lot, for example a bulk call spending 10 tokens instead of 1. Confidence: 0.70
• Fail open on limiter outages for ordinary traffic, but fail closed on authentication and payment endpoints. Confidence: 0.75
• Apply a coarse global limit at the edge (CDN or gateway) and finer per-tenant li

Python Type Hints taste of a typed-Python maintainer

• Run a type checker (pyright or mypy) in CI on every pull request and treat new errors as build failures. Confidence: 0.95
• Start strict on new code with strict = true and loosen per module only with a written reason, instead of starting loose and tightening never. Confidence: 0.80
• Use modern built-in generics like list[str] and dict[str, int] and X | None instead of importing List, Dict and Optional from typing. Confidence: 0.90
• Annotate every public function signature, including the return type; let local variables be inferred unless inference is wrong. Confidence: 0.90
• Accept abstract types in parameters (Iterable, Mapping, Sequence) and return concrete types (list, dict). Confidence: 0.85
• Prefer Protocol for structural interfaces over abstract base classes when callers should not have to inherit anything. Confidence: 0.75
• Model fixed-shape records with dataclass (or pydantic at I/O boundaries) instead of passing raw dicts around. Confidence: 0.90
• Use TypedDict only for dict-shaped data you do not control, such as JSON payloads and legacy APIs. Confidence: 0.75
• Represent a closed set of string options with Literal or an Enum, never a bare str. Confidence: 0.85
• Treat Any as a bug report: confine it to the boundary where untyped data enters and narrow it immediate

Tokio Async Rust taste of a production service engineer

• Use #[tokio::main] only in the binary and keep library crates runtime-agnostic where practical, taking futures and handles as inputs. Confidence: 0.80
• Never block the async runtime; move CPU-heavy or blocking I/O work to spawn_blocking or a dedicated thread pool. Confidence: 0.95
• Use tokio::sync::Mutex only when a lock must be held across an .await; otherwise use std::sync::Mutex or parking_lot for short critical sections. Confidence: 0.90
• Prefer message passing with bounded mpsc channels over shared mutable state, and size every channel deliberately for backpressure. Confidence: 0.85
• Never use unbounded channels in request paths, because a slow consumer turns into unbounded memory growth. Confidence: 0.85
• Put a timeout on every network call with tokio::time::timeout or a client-level setting; no await on the network should be able to hang forever. Confidence: 0.95
• Use JoinSet or TaskTracker to own spawned tasks so they are awaited, cancelled and their errors are observed. Confidence: 0.85
• Treat every .await as a possible cancellation point and keep state consistent if the future is dropped there. Confidence: 0.85
• Use select! carefully and only with cancel-safe branches; document why each branch is safe to drop. Confidence: 0.80
• Implement graceful shutdown with a `CancellationT

Tailwind CSS taste of a utility-first UI engineer

• Configure design tokens (colors, spacing, radii, fonts) once in the Tailwind theme and never hardcode hex values or arbitrary pixel sizes in markup. Confidence: 0.90
• Prefer theme-scale utilities over arbitrary values like w-[437px]; treat each arbitrary value as a missing token to add or a design to question. Confidence: 0.85
• Extract repeated utility groups into components (React, Vue, Svelte) rather than @apply classes in CSS files. Confidence: 0.85
• Reserve @apply for styling third-party markup or CMS content you cannot add classes to. Confidence: 0.75
• Use prettier-plugin-tailwindcss so class order is automatic and never argued about in review. Confidence: 0.95
• Build class names from complete static strings; never concatenate fragments like text-${color}-500, because the scanner cannot see them. Confidence: 0.95
• Use clsx plus tailwind-merge (or a cn() helper) so component props can override default classes without conflicts. Confidence: 0.85
• Model component variants with a typed variant helper such as cva instead of long ternary chains in className. Confidence: 0.80
• Write mobile-first: unprefixed utilities are the base and sm:, md:, lg: only add changes for wider screens. Confidence: 0.90
• Use container queries (@container, @md:) for reusable components whose layout depends on

Vite Frontend Tooling taste of a fast-feedback web developer

• Start new single-page apps and component playgrounds on Vite with the official framework plugin instead of a custom webpack setup. Confidence: 0.85
• Keep vite.config.ts in TypeScript with defineConfig, and keep it short enough to read in one screen. Confidence: 0.80
• Run type checking separately with tsc --noEmit in CI and in a watcher, since Vite only strips types and never checks them. Confidence: 0.95
• Use path aliases sparingly, define them once in tsconfig.json, and mirror them in Vite with a plugin such as vite-tsconfig-paths. Confidence: 0.75
• Expose only VITE_-prefixed environment variables to client code and never put secrets in them. Confidence: 0.95
• Type import.meta.env in a vite-env.d.ts file so missing or misspelled variables fail at compile time. Confidence: 0.80
• Configure the dev server proxy for backend APIs instead of enabling permissive CORS on the backend just for local development. Confidence: 0.85
• Use Vitest for unit and component tests so tests share the same config, transforms and aliases as the app. Confidence: 0.90
• Lazy-load routes and heavy widgets with dynamic import() and let Rollup split chunks, rather than hand-tuning manualChunks early. Confidence: 0.80
• Inspect bundle size with rollup-plugin-visualizer before releases and treat a large new dependen

Linux Server Hardening taste of a careful operations engineer

• Build servers from a minimal base image and install only the packages a role needs, removing compilers and debugging tools from production hosts. Confidence: 0.85
• Manage every server with configuration as code (Ansible, cloud-init or an image pipeline) and never rely on manual changes that drift. Confidence: 0.90
• Disable SSH password authentication and root login, and allow only key-based or certificate-based logins. Confidence: 0.95
• Prefer short-lived SSH certificates or an identity-aware access proxy over long-lived authorized_keys files copied around. Confidence: 0.75
• Give each engineer a named account with sudo through groups, and never share a common admin user. Confidence: 0.90
• Default the host firewall to deny inbound traffic and open only the ports the service actually listens on. Confidence: 0.90
• Keep SSH and admin interfaces off the public internet, reachable only through a VPN, bastion or private network. Confidence: 0.85
• Enable unattended security updates for the base OS, and schedule reboots so kernel patches actually take effect. Confidence: 0.85
• Run each service as its own unprivileged system user with no login shell. Confidence: 0.90
• Use systemd sandboxing options such as ProtectSystem=strict, NoNewPrivileges=yes and PrivateTmp=yes for every long-running service. Confidence