Top 30 Gitops Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   A team needs continuous drift detection for Kubernetes and configuration management for VMs and network gear with immutable audit trails. Which approach fits best?

   • aUse Kustomize overlays for all infrastructure since GitOps eliminates all drift across VMs and external cloud state.
   • bUse Ansible for both Kubernetes and network gear to avoid brittle Kustomize inheritance hierarchies beyond three or four environments.
   • cUse Ansible for everything because it provides native continuous drift reconciliation and works agentlessly across all infrastructure types.
   • dUse GitOps with Kustomize for Kubernetes and Ansible for VMs and network gear.
   Show the answer

   Answer: d · Use GitOps with Kustomize for Kubernetes and Ansible for VMs and network gear.

   The card states that hybrid VM and container estates often need both tools in tandem, using GitOps for Kubernetes drift detection and Ansible for diverse infrastructure. Option B is tempting because Kustomize overlays do become brittle beyond three to four environments, but abandoning GitOps sacrifices the required continuous drift detection and immutable audit trails for Kubernetes.

   Read the full bite: Compare GitOps and Kustomize vs Ansible for environment configs

2. Question 2 of 30

   In a GitOps workflow, how do you supply a database password to a Helm chart without exposing it in release metadata or requiring the app to reload file-based secrets?

   • aUse the Vault Secrets Operator to sync the password into a Kubernetes Secret that the chart mounts by name
   • bInject the password directly into pods via a Vault agent sidecar writing to a shared volume
   • cEncrypt the password with SOPS in a values file and decrypt it during CI before running helm install
   • dCreate the Kubernetes Secret manually with kubectl and reference its name in the Helm values file
   Show the answer

   Answer: a · Use the Vault Secrets Operator to sync the password into a Kubernetes Secret that the chart mounts by name

   Vault Secrets Operator keeps the credential out of Helm values entirely, preventing exposure in release metadata, while native Secret mounts avoid file-reload logic. SOPS-encrypted values are decrypted before Helm consumes them, so the plaintext password still ends up stored in Helm release metadata.

   Read the full bite: How do you securely manage and inject Helm secrets in CI/CD?

3. Question 3 of 30

   What is the primary advantage of adopting GitOps for MLOps workflows?

   • aIt eliminates the need for continuous integration/continuous deployment (CI/CD) pipelines in ML projects.
   • bIt establishes Git as the single, auditable source of truth for the entire ML system, ensuring reproducibility.
   • cIt enables data scientists to deploy models directly to production without any MLOps team involvement.
   • dIt simplifies data collection and feature engineering processes for ML models.
   Show the answer

   Answer: b · It establishes Git as the single, auditable source of truth for the entire ML system, ensuring reproducibility.

   The card explicitly states that GitOps provides a "unifying framework to manage this complexity by enforcing a single source of truth" and ensures "reproducibility" and "auditability." Option C is incorrect because the process involves "reviewable commit" and "pull request," indicating collaboration and review, not bypassing teams.

   Read the full bite: GitOps for MLOps: Your ML System as Code

4. Question 4 of 30

   Why is committing a SealedSecret to a public Git repo considered safe?

   • akubeseal strips the sensitive values before committing
   • bThe data is base64 encoded and obfuscated
   • cIt is encrypted with a public key only the cluster's private key can decrypt
   • dGit repos hide files marked as secrets
   Show the answer

   Answer: c · It is encrypted with a public key only the cluster's private key can decrypt

   kubeseal encrypts with the controller's public key, and only the in-cluster private key can decrypt, so the committed SealedSecret reveals nothing. Base64 is not encryption, and the values are encrypted, not stripped.

   Read the full bite: How do Sealed Secrets enable GitOps for secrets?

5. Question 5 of 30

   In a multi-step microservice provisioning pipeline, which property most directly enables safe recovery after a step fails midway?

   • aGranting the pipeline permanent root cloud credentials
   • bRunning all steps in a single shell script for speed
   • cDisabling retries so failures surface immediately
   • dMaking each step idempotent with compensating teardown for orphans
   Show the answer

   Answer: d · Making each step idempotent with compensating teardown for orphans

   Idempotent steps let you safely rerun the pipeline, and compensating teardown removes half-created resources. A single non-idempotent script offers no clean recovery, leaving orphaned repos or infrastructure after a partial failure.

   Read the full bite: Design automated microservice provisioning workflow

6. Question 6 of 30

   What is the primary function of the External Secrets Operator (ESO) in a Kubernetes cluster?

   • aTo continuously synchronize secrets from an external secret management system into standard Kubernetes Secret objects.
   • bTo encrypt all native Kubernetes Secrets at rest and manage their lifecycle within the cluster.
   • cTo serve as a secure, in-cluster secret storage solution, replacing external secret managers.
   • dTo enable applications to directly retrieve secrets from external providers using a unified API.
   Show the answer

   Answer: a · To continuously synchronize secrets from an external secret management system into standard Kubernetes Secret objects.

   ESO's core function is to act as a 'courier,' fetching secrets from an external source of truth (like AWS Secrets Manager or Vault) and injecting them into native Kubernetes Secrets, keeping them in sync. It is explicitly stated that ESO is 'not a secret store itself,' making option C incorrect.

   Read the full bite: External Secrets Operator: Sync Secrets into Kubernetes

7. Question 7 of 30

   What makes a SealedSecret safe to store in a public Git repository?

   • aIt is encrypted using a public key, and only the cluster's private key can decrypt it.
   • bIt contains no sensitive data itself, only references to secrets stored in an external vault.
   • cIt is obfuscated, not truly encrypted, making it difficult for attackers to reverse engineer.
   • dIt can only be decrypted by the kubeseal tool, which requires specific authentication.
   Show the answer

   Answer: a · It is encrypted using a public key, and only the cluster's private key can decrypt it.

   Sealed Secrets uses asymmetric encryption; the public key encrypts the secret, and only the corresponding private key, held securely within the target Kubernetes cluster, can decrypt it. This cryptographic protection makes the encrypted SealedSecret safe to store publicly. The kubeseal tool is used for encryption, not decryption, and the SealedSecret itself contains the encrypted data, not just references.

   Read the full bite: Sealed Secrets: Safely Commit K8s Secrets to Git

8. Question 8 of 30

   What is the primary mechanism by which a Kubernetes Sealed Secret is transformed into a usable Kubernetes Secret?

   • aDevelopers use the public key to manually decrypt the SealedSecret before applying it to the cluster.
   • bThe kubeseal CLI tool decrypts the SealedSecret manifest during application deployment.
   • cThe Kubernetes API server automatically decrypts the SealedSecret resource upon admission to the cluster.
   • dA dedicated controller within the target Kubernetes cluster uses a private key to decrypt the SealedSecret.
   Show the answer

   Answer: d · A dedicated controller within the target Kubernetes cluster uses a private key to decrypt the SealedSecret.

   The Sealed Secrets controller, running within the target cluster, is responsible for decrypting the SealedSecret using its private key. The kubeseal CLI tool is used for encryption, not decryption, and the Kubernetes API server does not perform the decryption itself.

   Read the full bite: Kubernetes Sealed Secrets: Git-Friendly Secret Management

9. Question 9 of 30

   A developer manually scales a Deployment to seven replicas via kubectl, but Git declares three. What does the GitOps agent do on its next reconciliation?

   • aUpdate the Git repository to match the live seven-replica state
   • bDo nothing because the change did not originate from Git
   • cScale the Deployment back to three replicas to match Git
   • dWait for manual approval before making any changes
   Show the answer

   Answer: c · Scale the Deployment back to three replicas to match Git

   The GitOps agent continuously reconciles live cluster state against Git as the single source of truth, so it self-heals by scaling back to three. Distractor B is wrong because Git, not the live cluster, is the authoritative desired state, so the agent does not write drift back to the repository.

   Read the full bite: Explain GitOps and how an agent knows when to apply changes

10. Question 10 of 30

    After CI updates the image tag in the Git repository, how is the new version deployed in a GitOps workflow?

    • aThe CI pipeline pushes the update directly to the cluster using kubectl apply
    • bThe cluster watches the container registry and automatically rolls out the new image tag
    • cThe GitOps controller detects the manifest change and reconciles the cluster state to match Git
    • dA release engineer manually triggers a sync job to update the live deployment
    Show the answer

    Answer: c · The GitOps controller detects the manifest change and reconciles the cluster state to match Git

    In GitOps, the GitOps controller continuously compares the declarative desired state in Git with the live cluster state and automatically reconciles differences, so the cluster converges to what is defined in version control. The distractor describing CI pushing directly with kubectl apply describes a traditional push-based pipeline, which violates the GitOps principle of keeping cluster access out of the build stage and fails to use Git as the single source of truth.

    Read the full bite: Walk me through deploying a new version using a GitOps workflow

11. Question 11 of 30

    Which strategy best protects sensitive credentials while maintaining Git as the declarative source of truth in a GitOps workflow?

    • aEncrypt the credentials at rest using Sealed Secrets or SOPS so only the target cluster can decrypt them
    • bStore the credentials as plain text in a private repository with strict role-based access controls
    • cApply the credentials manually with kubectl outside the GitOps pipeline and reference them in Git manifests
    • dEncode the credentials with Base64 in standard Kubernetes Secret manifests before committing them
    Show the answer

    Answer: a · Encrypt the credentials at rest using Sealed Secrets or SOPS so only the target cluster can decrypt them

    Encrypting secrets at rest with Sealed Secrets or SOPS keeps sensitive values out of plaintext while preserving Git as the automated source of truth. The most tempting distractor is storing plaintext in a private repository, but access controls alone do not prevent exposure to anyone with read access and offer no protection against accidental leaks.

    Read the full bite: How do you secure secrets in a GitOps repository?

12. Question 12 of 30

    Which GitOps repository layout reduces controller polling overhead but makes promoting changes across environments harder?

    • aA single repository where each controller watches only its environment subdirectory
    • bOne repository using Git branches per environment
    • cA monorepo with Kustomize overlays per environment
    • dA separate repository for each environment
    Show the answer

    Answer: d · A separate repository for each environment

    Repository-per-environment shrinks the state store so controllers poll less, yet promoting fixes requires replicating commits across repos. Branch-per-environment is the most tempting distractor because it is a common anti-pattern: branches are mutable pointers, so they destroy immutable desired-state traceability and invite drift.

    Read the full bite: Two common GitOps repository layouts for multiple environments

13. Question 13 of 30

    An on-call engineer runs kubectl set image during an outage but never commits the change. With automated sync enabled, what should the GitOps tool do?

    • aIgnore the difference because manual edits are valid break-glass changes
    • bPush the live image change back into Git automatically
    • cRevert the deployment image to match the version declared in Git
    • dPause reconciliation and alert the team to choose the correct state
    Show the answer

    Answer: c · Revert the deployment image to match the version declared in Git

    Automated self-healing sync is designed to enforce Git as the single source of truth by reverting live deviations. Pausing reconciliation breaks the GitOps contract, and ignoring the drift would leave the cluster in an un-auditable state.

    Read the full bite: What is configuration drift in GitOps and how do tools handle it?

14. Question 14 of 30

    In a GitOps pipeline deploying a microservice to Kubernetes, which approach best handles database schema migrations while preserving declarative source-of-truth principles?

    • aEmbed migration logic in the application startup so each replica synchronizes schema before serving traffic
    • bKeep migrations outside of Git and require a DBA to run them manually prior to each Argo CD sync
    • cUse Terraform with a SQL provider to manage both the database instance and the live schema state in a single declarative apply
    • dVersion migration files in Git and execute them through an idempotent pre-sync job using a dedicated schema tool, separate from infrastructure provisioning
    Show the answer

    Answer: d · Version migration files in Git and execute them through an idempotent pre-sync job using a dedicated schema tool, separate from infrastructure provisioning

    Versioned migration files executed by a dedicated schema tool via a pre-sync hook preserve Git as the source of truth while ensuring the schema is ready before the app starts. Using a Terraform SQL provider to manage live schema state incorrectly couples infrastructure provisioning with imperative data lifecycle operations and risks partial failures.

    Read the full bite: Describe a robust strategy for GitOps database schema migrations

15. Question 15 of 30

    In a hub-and-spoke GitOps cluster lifecycle workflow, how should day-two addons like CNI or CSI drivers be delivered to ephemeral workload clusters?

    • aConfigure the CI pipeline to run kubectl apply against workload clusters whenever addon files change in Git
    • bEmbed addon bootstrap commands into Cluster API machine templates so nodes join with addons pre-installed
    • cStore addon definitions in Git and have the management cluster's Flux apply them via HelmRelease or Kustomization resources using workload cluster KubeConfig secrets
    • dRun a dedicated GitOps agent inside each workload cluster to pull addon manifests directly from Git
    Show the answer

    Answer: c · Store addon definitions in Git and have the management cluster's Flux apply them via HelmRelease or Kustomization resources using workload cluster KubeConfig secrets

    The management cluster's Flux reconciles addon manifests from Git and pushes them to each ephemeral workload cluster using stored KubeConfig secrets, keeping delivery declarative and auditable. Running an agent inside the workload cluster it manages is a bootstrap error, because that cluster may not yet exist or may be torn down, breaking the GitOps loop.

    Read the full bite: How would you use GitOps to manage Kubernetes cluster lifecycles?

16. Question 16 of 30

    Which architectural approach best balances developer autonomy with hard guardrails in a multi-tenant Kubernetes GitOps platform?

    • aAllow teams to self-manage admission policies in their namespaces while the platform team audits violations post-deployment
    • bScope GitOps tenants to namespaces and enforce immutable deny policies via admission controllers synced from a restricted central repo
    • cShare one cluster-admin GitOps instance across all teams and mitigate risky resources with network policies after creation
    • dCentralize all application manifests and policies in one repo reviewed by the platform team, using CI linting as the sole enforcement point
    Show the answer

    Answer: b · Scope GitOps tenants to namespaces and enforce immutable deny policies via admission controllers synced from a restricted central repo

    Namespace-scoped GitOps with admission webhooks synced from a restricted policy repo lets teams self-service while preventing bypass at the API server. Relying on manual reviews or CI-only enforcement creates a bottleneck and leaves the cluster exposed to direct kubectl apply or compromised credentials.

    Read the full bite: How do you architect self-service GitOps with central policy enforcement?

17. Question 17 of 30

    What distinguishes true GitOps from a CI job that simply runs kubectl apply from the pipeline?

    • aIt requires using GitHub specifically as the host
    • bIt stores YAML in Git instead of a database
    • cIt forbids using Helm charts in the repository
    • dAn in-cluster controller continuously reconciles live state to Git
    Show the answer

    Answer: d · An in-cluster controller continuously reconciles live state to Git

    GitOps centers on a controller that continuously pulls desired state from Git and corrects drift, not a one-shot push from CI. Storing YAML in Git or the choice of host or templating tool is incidental.

    Read the full bite: What is the basic principle of GitOps?

18. Question 18 of 30

    In a secure multi-environment deployment platform, what is the primary architectural benefit of requiring environment-local agents to pull deployments rather than allowing a central orchestrator to push?

    • aIt ensures the central platform does not store or manage long-lived credentials capable of reaching production environments.
    • bIt lets developers directly trigger production deployments from local machines for faster iteration.
    • cIt enforces identical manifests across all environments by eliminating per-environment configuration overlays.
    • dIt removes the need for network connectivity between the control plane and environments behind firewalls.
    Show the answer

    Answer: a · It ensures the central platform does not store or manage long-lived credentials capable of reaching production environments.

    Pull agents let the central platform orchestrate without holding long-lived secrets that could reach production, enforcing least privilege and shrinking blast radius. Distractor A is tempting because firewalls complicate connectivity, but the architecture still requires outbound polling over mTLS rather than eliminating network requirements entirely.

    Read the full bite: How would you architect deployment capabilities for multiple disparate environments?

19. Question 19 of 30

    An engineer manually scales a Deployment with kubectl, but no Git commit was made. Will a GitOps controller flag it?

    • aNo, because manual kubectl changes are outside the controller's scope
    • bNo, because drift is only detected when a new commit lands in Git
    • cOnly if a webhook was configured for that namespace
    • dYes, because it diffs live state against Git regardless of which side changed
    Show the answer

    Answer: d · Yes, because it diffs live state against Git regardless of which side changed

    The controller continuously compares rendered desired state to live cluster state, so a manual change creates a diff and an OutOfSync status. It does not depend on a Git commit or a webhook to notice drift.

    Read the full bite: How GitOps controllers detect drift and sync

20. Question 20 of 30

    Why is committing a standard Kubernetes Secret to Git unsafe even though the value is base64-encoded?

    • aKubernetes rejects base64 Secrets that originate from Git
    • bbase64 only protects values shorter than 32 characters
    • cGit automatically strips encoding from committed files
    • dbase64 is reversible encoding, not encryption, so anyone can decode it
    Show the answer

    Answer: d · base64 is reversible encoding, not encryption, so anyone can decode it

    base64 is trivially decodable, so it offers no confidentiality; the secret is effectively plaintext. Real protection requires encryption such as Sealed Secrets or SOPS, or referencing an external store.

    Read the full bite: Managing secrets in a GitOps workflow

21. Question 21 of 30

    In the App of Apps pattern, what does the Git path referenced by the root Application actually contain?

    • aOnly ConfigMaps that store deployment metadata
    • bThe cluster's etcd snapshot for restore
    • cHelm chart binaries packaged as tarballs
    • dOther Argo CD Application manifests, not raw workload resources
    Show the answer

    Answer: d · Other Argo CD Application manifests, not raw workload resources

    The root app points at a path of child Application resources; syncing it creates those children, which then deploy the real workloads. The root itself does not contain the workload manifests.

    Read the full bite: Argo CD App of Apps pattern

22. Question 22 of 30

    Why is a directory-based overlay layout generally preferred over a branch-per-environment GitOps layout?

    • aIt avoids merge drift and makes version promotion an explicit, reviewable change
    • bIt eliminates the need for a GitOps controller to reconcile
    • cIt lets all environments share a single live cluster namespace
    • dIt removes the need for any environment-specific configuration
    Show the answer

    Answer: a · It avoids merge drift and makes version promotion an explicit, reviewable change

    Directory overlays make each environment's pinned version visible and promotion a simple PR, sidestepping the cherry-pick and merge drift that plague branch-per-environment. Environment-specific config still exists, living in each overlay.

    Read the full bite: GitOps repo layout for environment promotion

23. Question 23 of 30

    Why must a Helm pre-upgrade migration hook be idempotent when run under a continuously reconciling GitOps controller?

    • aIdempotency is required only for post-install hooks, not pre-upgrade
    • bA re-sync can recreate and rerun the hook Job, so it may execute more than once
    • cGitOps controllers run every hook exactly twice by design
    • dHelm hooks are ignored entirely, so the script never runs
    Show the answer

    Answer: b · A re-sync can recreate and rerun the hook Job, so it may execute more than once

    Because the controller reconciles declaratively and may recreate the hook Job on each sync, a non-idempotent migration could run repeatedly and corrupt data. The hook is not ignored; it is translated to the controller's own sync phases.

    Read the full bite: Helm migration hooks under GitOps

24. Question 24 of 30

    What is the primary mechanism by which GitOps ensures infrastructure consistency?

    • aDevelopers manually apply configuration changes directly to the live system after approval.
    • bA central CI/CD pipeline pushes configuration updates from Git to the infrastructure.
    • cAutomated agents continuously pull desired state from a Git repository and reconcile the live environment.
    • dInfrastructure state is regularly backed up to Git, allowing for manual restoration if drift occurs.
    Show the answer

    Answer: c · Automated agents continuously pull desired state from a Git repository and reconcile the live environment.

    The card states that "software agents inside your environment automatically PULL the desired state from the source repo" and "these agents CONTINUOUSLY RECONCILE the actual state of the system with the desired state." Option B describes a push-based model, which is contrary to GitOps' pull-based nature.

    Read the full bite: GitOps Principles: Your Repo as the Source of Truth

25. Question 25 of 30

    A regulated org must make every production model change reviewable and auditable. Which platform approach best supports this, and what is its main cost?

    • aImperative SDK; cost is reduced flexibility for scientists
    • bDeclarative GitOps config; cost is loss of audit trails
    • cDeclarative GitOps config; cost is verbosity and a steeper learning curve
    • dImperative SDK; cost is poor reproducibility
    Show the answer

    Answer: c · Declarative GitOps config; cost is verbosity and a steeper learning curve

    Declarative GitOps puts every change in a reviewable, version-controlled commit, giving the audit trail and reproducibility regulators need, at the cost of verbosity and a learning curve. Imperative SDKs make auditing harder, not easier.

    Read the full bite: Declarative vs imperative ML platform design

26. Question 26 of 30

    Your team adds schema validation in CI after a GitOps outage. Why is that alone insufficient to prevent a similar incident?

    • aSchema validation should be replaced by disabling auto-sync entirely
    • bSchema validation cannot catch logic or resourcing errors; you also need dry-run, policy, and post-merge health gates with rollback
    • cSchema validation already guarantees the cluster will be healthy after sync
    • dPost-merge checks are redundant once CI passes
    Show the answer

    Answer: b · Schema validation cannot catch logic or resourcing errors; you also need dry-run, policy, and post-merge health gates with rollback

    Schema validation only confirms structure, not whether a valid manifest behaves correctly. Layered guardrails, server-side dry-run, policy as code, and post-merge health checks with rollback, are needed because no single gate catches every failure.

    Read the full bite: Guardrails for GitOps sync outages

27. Question 27 of 30

    In a GitOps workflow, what is the main objective of implementing configuration drift detection?

    • aTo monitor the performance and health metrics of applications deployed via GitOps.
    • bTo identify and report any deviations between the desired state in Git and the actual state of the live system.
    • cTo automatically synchronize the live environment with the Git repository whenever a change is detected.
    • dTo enforce a strict policy that disallows any direct modifications to resources in the live cluster.
    Show the answer

    Answer: b · To identify and report any deviations between the desired state in Git and the actual state of the live system.

    The card explicitly states that drift detection was created to "automatically find and flag these out-of-band modifications" by comparing the desired state in Git with the live state. While GitOps tools might automatically synchronize (option C) after detection, the primary objective of the detection mechanism itself is the identification and reporting of discrepancies. Option D is incorrect because drift detection flags changes, it doesn't prevent them from being made.

    Read the full bite: Configuration Drift: When Live State Betrays Git

28. Question 28 of 30

    What mechanism does Argo CD use to ensure resources in a higher sync wave are applied only after those in a lower wave are fully operational?

    • aIt confirms that the Kubernetes API server has successfully processed the manifests for the preceding wave.
    • bIt verifies that all resources in the preceding wave have achieved a healthy status.
    • cIt leverages Kubernetes' native object dependency graph for sequential application.
    • dIt executes a dedicated pre-sync hook to validate the readiness of the preceding wave.
    Show the answer

    Answer: b · It verifies that all resources in the preceding wave have achieved a healthy status.

    Option B is correct because the card states that resources in a wave are only applied after all resources in the previous wave become healthy. Option A is incorrect as merely processing manifests does not guarantee a resource is fully operational; it needs to reach a healthy status.

    Read the full bite: Argo CD Sync Phases and Waves: Ordering Your Deployments

29. Question 29 of 30

    What is the primary role of Flux's image update automation in a GitOps workflow?

    • aAutomatically updating image tags in the Git repository to trigger deployments.
    • bEnforcing security policies by scanning container images for vulnerabilities.
    • cAutomating the build and push of new container images to a registry.
    • dManaging the scaling and self-healing of deployed applications in Kubernetes.
    Show the answer

    Answer: a · Automatically updating image tags in the Git repository to trigger deployments.

    The card states that image update automation 'automatically commits the change back to your Git repository, triggering a deployment' to bridge the gap between the image registry and Git. Option C describes CI/CD build steps, not Flux's automation.

    Read the full bite: Flux Image Update Automation: Closing the GitOps Loop

30. Question 30 of 30

    Which statement best describes Flux CD's primary role in a software delivery pipeline?

    • aIt automates infrastructure provisioning and configuration management for various cloud platforms.
    • bIt pushes new application images from a CI system directly to the Kubernetes cluster.
    • cIt continuously synchronizes Kubernetes cluster state with configurations defined in a Git repository.
    • dIt compiles application code and runs unit tests before deploying to Kubernetes.
    Show the answer

    Answer: c · It continuously synchronizes Kubernetes cluster state with configurations defined in a Git repository.

    Flux CD's core function is to ensure the live state of a Kubernetes cluster continuously matches the desired configuration specified in a Git repository, making Git the source of truth for continuous delivery. It does not perform CI tasks like compiling code or running tests, nor is it a general-purpose automation tool for non-Kubernetes infrastructure.

    Read the full bite: Flux CD: Git as the Source of Truth for Kubernetes