Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: DevOps · Уровень: Middle+/Senior

## TL;DR
- **GitHub Actions**: единица — *workflow* (`.github/workflows/*.yml`), внутри *jobs*, внутри *steps*. Шаги — это либо shell-команды (`run`), либо переиспользуемые *actions* (`uses`). Jobs по умолчанию параллельны, изолированы (разные раннеры), связываются через `needs`.
- **GitLab CI**: единица — `.gitlab-ci.yml`, внутри *jobs*, сгруппированные по *stages*. Stages выполняются последовательно, jobs внутри одного stage — параллельно. Артефакты передаются между stages через `artifacts`/`dependencies`.
- **Кэширование** обязательно для Go: кэшируем `$GOMODCACHE` (`~/go/pkg/mod`) и build cache (`~/.cache/go-build`). В GH Actions — `actions/cache` или `setup-go` с `cache: true`; в GitLab — `cache:` с ключом по `go.sum`.
- **Матрицы** (`strategy.matrix` / `parallel.matrix`) гоняют один job по комбинациям (версии Go, ОС, arch).
- **Секреты**: GH — Secrets (repo/org/environment) + OIDC для облаков без статичных ключей; GitLab — CI/CD variables (masked, protected, file). Никогда не печатать в лог.
- Концептуально оба про одно: декларативный pipeline-as-code, изолированные раннеры, кэш, артефакты, секреты, матрицы.

## Теория

### GitHub Actions: модель

```yaml
# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:

# отмена устаревших запусков на тот же ref
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read           # принцип наименьших привилегий для GITHUB_TOKEN

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.22'
          cache: true                 # кэширует mod cache + build cache по go.sum
      - run: go vet ./...
      - run: go test -race -coverprofile=cover.out ./...
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: cover.out
```

- `on` — триггеры (push, pull_request, schedule (cron), workflow_dispatch (ручной), tags).
- `runs-on` — тип раннера (GitHub-hosted или self-hosted).
- `jobs.<id>.needs` — зависимости между job (DAG).
- `uses` — переиспользуемый action (всегда пинить версию: `@v4` или, безопаснее, по SHA коммита).
- `GITHUB_TOKEN` — автогенерируемый токен; ограничивайте через `permissions`.

### GitHub Actions: stages эмулируются через `needs`
В GH нет явных stages. Последовательность задаётся графом `needs`:

```yaml
jobs:
  lint:   { runs-on: ubuntu-latest, steps: [...] }
  test:   { runs-on: ubuntu-latest, steps: [...] }
  build:
    needs: [lint, test]           # запустится только после успеха обоих
    runs-on: ubuntu-latest
    steps: [...]
  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'   # только из main
    environment: production               # защита + approval
    runs-on: ubuntu-latest
    steps: [...]
```

### GitLab CI: модель

```yaml
# .gitlab-ci.yml
stages: [lint, test, build, deploy]

variables:
  GOFLAGS: "-mod=readonly"

default:
  image: golang:1.22

lint:
  stage: lint
  script:
    - go vet ./...
    - golangci-lint run ./...

test:
  stage: test
  script:
    - go test -race -coverprofile=cover.out ./...
  coverage: '/coverage: \d+\.\d+% of statements/'
  artifacts:
    paths: [cover.out]
    expire_in: 1 week

build:
  stage: build
  script:
    - go build -o app ./cmd/app
  artifacts:
    paths: [app]

deploy:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'   # только main
  environment:
    name: production
```

- `stages` — порядок исполнения; job привязан к stage через `stage:`.
- jobs одного stage идут параллельно; следующий stage стартует после успеха всех job предыдущего.
- `rules` (новый способ) / `only/except` (старый) — условия запуска job.
- `artifacts` — передаются вниз по stages автоматически (или выборочно через `dependencies`/`needs`).
- `needs:` в GitLab позволяет строить DAG поверх stages (job стартует, как только готовы его зависимости, не дожидаясь всего stage).

### Кэширование

**GitHub Actions** — `setup-go` с `cache: true` достаточно в 90% случаев. Ручной вариант:

```yaml
- uses: actions/cache@v4
  with:
    path: |
      ~/.cache/go-build
      ~/go/pkg/mod
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: ${{ runner.os }}-go-
```

**GitLab CI**:

```yaml
test:
  cache:
    key:
      files: [go.sum]          # инвалидация при изменении зависимостей
    paths:
      - .go/pkg/mod/
      - .go-build/
  variables:
    GOPATH: "$CI_PROJECT_DIR/.go"
    GOCACHE: "$CI_PROJECT_DIR/.go-build"
```

Ключевая идея: ключ кэша зависит от `go.sum`. Изменился `go.sum` → новый ключ → пересборка кэша. `restore-keys` (GH) даёт частичное попадание по префиксу. Кэш — оптимизация, билд обязан работать и без него.

### Матрицы

**GitHub Actions**:

```yaml
jobs:
  test:
    strategy:
      fail-fast: false          # не отменять остальные при падении одного
      matrix:
        go: ['1.21', '1.22']
        os: [ubuntu-latest, macos-latest]
        include:                # добавить точечную комбинацию
          - go: '1.22'
            os: ubuntu-latest
            coverage: true
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/setup-go@v5
        with: { go-version: '${{ matrix.go }}' }
```

**GitLab CI**:

```yaml
test:
  stage: test
  parallel:
    matrix:
      - GO_VERSION: ['1.21', '1.22']
  image: golang:$GO_VERSION
  script: go test ./...
```

### Секреты и безопасность

**GitHub**: Secrets на уровне repo/org/environment, доступны как `${{ secrets.NAME }}`. Они автоматически маскируются в логах. Для облаков — **OIDC**: workflow получает короткоживущий токен от облака (AWS/GCP) без хранения статичных ключей.

```yaml
permissions:
  id-token: write            # нужно для OIDC
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789:role/ci-deploy
      aws-region: eu-central-1
```

**GitLab**: CI/CD variables с флагами:
- *masked* — скрывается в логах;
- *protected* — доступна только в protected branches/tags (защита от утечки через форк/feature-ветку);
- *file* — значение кладётся во временный файл (для kubeconfig, JSON-ключей).

GitLab также поддерживает OIDC через `id_tokens` для облаков и Vault.

### Типовой полный Go-пайплайн (GitHub Actions)

```yaml
name: CI/CD
on:
  push: { branches: [main] }
  pull_request:
permissions: { contents: read }
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with: { go-version: '1.22', cache: true }
      - run: gofmt -l . | tee /dev/stderr | (! read)   # fail, если есть неформатированное
      - run: go vet ./...
      - uses: golangci/golangci-lint-action@v6
      - run: go test -race -coverprofile=cover.out ./...
      - run: go run golang.org/x/vuln/cmd/govulncheck@latest ./...

  release:
    needs: ci
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions: { contents: read, packages: write, id-token: write }
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:sha-${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
```

## Подводные камни / gotchas
- **Не пиннингованные actions** (`uses: foo/bar@main`) — supply chain риск: мейнтейнер или взлом может подменить код. Пинить по SHA коммита для критичных.
- **Избыточные `permissions`** у `GITHUB_TOKEN` — по умолчанию могут быть широкими. Ставьте `contents: read` и расширяйте точечно.
- **Секреты недоступны в workflow из форка** (`pull_request` от внешнего контрибьютора) — by design, иначе утечка. Для нужных кейсов есть `pull_request_target`, но он опасен (выполняет код базовой ветки с секретами) — легко открыть RCE.
- **GitLab: незащищённые переменные в feature-ветках** — если variable не *protected*, её можно вытащить через push ветки с `echo`. Секреты деплоя делайте protected.
- **Кэш не инвалидируется** при смене go-версии, если ключ только по `go.sum` — добавляйте версию в ключ.
- **`fail-fast: true` (дефолт) в матрице** отменяет все job при первом падении — теряете информацию, какие комбинации ещё сломаны. Для диагностики `fail-fast: false`.
- **GitLab stages блокируют параллелизм**: build ждёт ВСЕ test-job. `needs:` (DAG) ускоряет, запуская job по готовности зависимостей.
- **Артефакты не передаются автоматически в GH Actions между jobs** (разные раннеры) — нужен `upload/download-artifact`. В GitLab внутри pipeline передаются по stages.
- **`gofmt -l .` сам по себе не падает** (exit 0 даже при наличии файлов) — нужен трюк, чтобы непустой вывод дал ненулевой код.

## Вопросы на собеседовании
**В:** Чем отличается модель выполнения GitHub Actions от GitLab CI?
**О:** В GitLab есть явные последовательные *stages*, jobs внутри stage параллельны, следующий stage ждёт весь предыдущий (ускоряется через `needs`/DAG). В GitHub Actions явных stages нет — порядок задаётся графом `needs` между jobs; jobs изолированы на разных раннерах, поэтому данные между ними передаются только через артефакты.

**В:** Как правильно кэшировать зависимости в Go-пайплайне?
**О:** Кэшируем module cache (`~/go/pkg/mod`) и build cache (`~/.cache/go-build`). Ключ кэша — хэш `go.sum` (+ ОС/версия Go), чтобы инвалидироваться при смене зависимостей. В GH проще всего `setup-go` с `cache: true`; в GitLab — `cache.key.files: [go.sum]`. Кэш должен только ускорять, билд обязан проходить и на холодную.

**В:** Что такое OIDC в CI и зачем он нужен?
**О:** Вместо хранения долгоживущих ключей облака, CI получает короткоживущий токен через OpenID Connect: облако доверяет identity provider'у CI и выдаёт временные креды под конкретную роль. Это убирает статичные секреты (которые утекают и не ротируются), сужает доступ до конкретного repo/ветки/окружения.

**В:** Зачем ограничивать `permissions` у `GITHUB_TOKEN`?
**О:** По умолчанию токен может иметь широкие права на репозиторий. Скомпрометированный шаг (например, вредная transitive-зависимость в build) сможет ими воспользоваться (запушить, создать релиз). Принцип наименьших привилегий: `contents: read` и расширение точечно (`packages: write`, `id-token: write`) только там, где нужно.

**В:** Почему секреты недоступны в pull_request от форка и что такое pull_request_target?
**О:** Иначе любой внешний контрибьютор подсунул бы код, печатающий секреты в лог. Поэтому `pull_request` от форка идёт без секретов. `pull_request_target` запускает workflow в контексте базовой ветки (с секретами), но с кодом PR — это опасно, легко получить выполнение чужого кода с секретами; использовать крайне осторожно, не чекаутить и не запускать код PR.

**В:** Как сделать так, чтобы job деплоя запускался только из main?
**О:** GH: `if: github.ref == 'refs/heads/main'` + `needs` на CI + `environment` с required reviewers для approval. GitLab: `rules: - if: '$CI_COMMIT_BRANCH == "main"'` + `environment`. Дополнительно protected branches/variables, чтобы деплойные секреты были недоступны вне main.

**В:** Что такое матрица сборки и когда `fail-fast: false`?
**О:** Матрица гоняет один job по комбинациям параметров (версии Go, ОС, arch). `fail-fast: false` нужен, когда хочется увидеть все падающие комбинации сразу (диагностика совместимости), а не останавливать всё на первом фейле. Для быстрой обратной связи на PR дефолтный `true` экономит ресурсы.

**В:** Как передать собранный артефакт из одного job в другой в GitHub Actions?
**О:** Через `actions/upload-artifact` в продьюсере и `actions/download-artifact` в консьюмере — потому что jobs выполняются на разных изолированных раннерах и не делят файловую систему. В GitLab внутри одного pipeline артефакты передаются по stages автоматически (или выборочно через `dependencies`/`needs`).

## На что копают на senior+
- Supply chain security в CI: пиннинг actions по SHA, проверка provenance, минимальные permissions, изоляция untrusted PR.
- Reusable workflows (GH `workflow_call`) / GitLab `include` + `extends` + templates — DRY для десятков сервисов в организации.
- Self-hosted runners: изоляция, эфемерность (один job — один раннер), безопасность (untrusted code на своих машинах), autoscaling.
- Оптимизация времени: разделение fast/slow job, path filters для монорепо, кэш Docker-слоёв (`type=gha`, registry cache), параллелизм.
- Стратегии деплоя из пайплайна: environments, approval-гейты, OIDC, интеграция с ArgoCD/Helm.
- Управление секретами на масштабе: external secret managers (Vault, cloud secret manager), ротация, отсутствие секретов в форках.