Home/Cloud & DevOps/Page 3
Cloud & DevOps
Share
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Why does my Terraform apply succeed but resources don’t actually exist?
Terraform probably applied the resources somewhere other than where you’re looking. This happens when credentials point to a different account, subscription, or region than expected. Terraform doesn’t warn you if you’re authenticated correctly but targeting the wrong environment—it just applies succRead more
Terraform probably applied the resources somewhere other than where you’re looking.
This happens when credentials point to a different account, subscription, or region than expected. Terraform doesn’t warn you if you’re authenticated correctly but targeting the wrong environment—it just applies successfully.
This is especially common in CI setups where multiple cloud credentials exist side by side.
Takeaway: Always verify account and region before assuming Terraform didn’t work.
See lessWhy does my CI pipeline fail only on merge but pass on pull requests?
Merge pipelines and pull request pipelines often run under different security rules, even though the code is the same. Many CI systems restrict secrets, credentials, or cloud access depending on how the pipeline was triggered. A pipeline running on a merge to the main branch might use a different idRead more
Merge pipelines and pull request pipelines often run under different security rules, even though the code is the same.
Many CI systems restrict secrets, credentials, or cloud access depending on how the pipeline was triggered. A pipeline running on a merge to the main branch might use a different identity, environment, or permission set than one running on a pull request.
This makes failures feel inconsistent, but the difference is usually intentional from a security perspective.
Takeaway: When CI behaves differently, compare identities and secrets—not code changes.
See lessWhy are my cloud costs increasing even though traffic hasn’t changed?
Stable traffic doesn’t guarantee stable cost. Idle resources, misconfigured autoscaling, forgotten snapshots, and pricing model changes all contribute to rising bills without any traffic increase. Autoscaling that grows quickly but shrinks slowly is a particularly common cause. Costs usually grow quRead more
Stable traffic doesn’t guarantee stable cost.
Idle resources, misconfigured autoscaling, forgotten snapshots, and pricing model changes all contribute to rising bills without any traffic increase. Autoscaling that grows quickly but shrinks slowly is a particularly common cause.
Costs usually grow quietly until someone checks the bill.
Takeaway: Cost control requires auditing idle and scaling resources, not just traffic.
See lessWhy does my Azure VM fail to access storage even though the managed identity has permissions?
A managed identity must be reachable and correctly scoped before it can be used. If the VM can’t obtain tokens, the issue is often networking, disabled identity endpoints, or role assignments applied at the wrong scope. Even when everything is correct, permission changes can take a few minutes to prRead more
A managed identity must be reachable and correctly scoped before it can be used.
If the VM can’t obtain tokens, the issue is often networking, disabled identity endpoints, or role assignments applied at the wrong scope. Even when everything is correct, permission changes can take a few minutes to propagate.
People often assume identity assignment is instant and global, which leads to confusion during testing.
Takeaway: Managed identities depend on both token access and correct scope.
See lessWhy does my Kubernetes pod stay in CrashLoopBackOff with no obvious error logs?
This happens when the container exits too quickly for logs to be captured, usually because it fails during startup. If a container crashes immediately due to a bad command, missing file, or failed initialization, Kubernetes restarts it repeatedly. The useful error often appears only in the previousRead more
This happens when the container exits too quickly for logs to be captured, usually because it fails during startup.
If a container crashes immediately due to a bad command, missing file, or failed initialization, Kubernetes restarts it repeatedly. The useful error often appears only in the previous container run, not the current one. Pod events are also important here, because probes or exit codes often explain what’s happening long before logs do.
Many people focus only on live logs and miss the fact that Kubernetes keeps a short history of failed runs.
Takeaway: When logs look empty, pod events and previous container logs usually explain the crash.
See lessWhy does my autoscaling group terminate healthy instances?
Autoscaling is focused on meeting capacity targets, not preserving individual instances. If scale-in policies are aggressive and instance protection isn’t enabled, the autoscaler will happily terminate healthy instances to reduce capacity. From its perspective, everything is working as designed. ProRead more
Autoscaling is focused on meeting capacity targets, not preserving individual instances.
If scale-in policies are aggressive and instance protection isn’t enabled, the autoscaler will happily terminate healthy instances to reduce capacity. From its perspective, everything is working as designed.
Problems arise when workloads aren’t prepared for termination or don’t drain gracefully before shutdown.
Takeaway: Autoscaling protects numbers, not workloads, unless you configure it to.
See lessWhy does my Docker container fail with “permission denied” when writing files?
This happens because the container is running as a non-root user and doesn’t have permission to write to the directory it’s trying to use. Many modern images intentionally drop root privileges for security reasons. That’s good practice, but it means directories owned by root are no longer writable uRead more
This happens because the container is running as a non-root user and doesn’t have permission to write to the directory it’s trying to use.
Many modern images intentionally drop root privileges for security reasons. That’s good practice, but it means directories owned by root are no longer writable unless you explicitly change ownership or permissions. This often shows up when mounting volumes or writing logs at runtime.
It’s especially confusing because everything may work fine locally if you were previously running the container as root.
Takeaway: Non-root containers are safer, but you must explicitly manage file ownership.
See lessWhy does my Docker container exit immediately with code 0?
An exit code of 0 means the container completed successfully—but probably not what you expected. This usually happens when the container’s main process finishes instantly, such as running a script instead of a long-running service. Check the CMD or ENTRYPOINT in your Dockerfile. If you intended to kRead more
An exit code of 0 means the container completed successfully—but probably not what you expected.
This usually happens when the container’s main process finishes instantly, such as running a script instead of a long-running service. Check the
CMDorENTRYPOINTin your Dockerfile.If you intended to keep the container alive, ensure the main process blocks (for example, a web server or worker loop).
Takeaway: Containers live only as long as their main process runs.
See lessWhy does my CI pipeline succeed locally but fail in GitHub Actions with permission errors?
Takeaway: If it works locally but not in CI, suspect credentials—not code. Local environments often have cached credentials or broader permissions that CI runners do not. In CI, authentication must be explicit. Missing environment variables, incorrect service account bindings, or restrictive IAM rolRead more
Takeaway: If it works locally but not in CI, suspect credentials—not code.
Local environments often have cached credentials or broader permissions that CI runners do not.
In CI, authentication must be explicit. Missing environment variables, incorrect service account bindings, or restrictive IAM roles commonly cause failures that don’t reproduce locally.
Log the identity being used inside the pipeline and verify it matches what you expect. For cloud access, always assume the CI identity is less privileged than your local one.
See lessWhy does my EC2 instance fail with “Unable to locate credentials” even though an IAM role is attached?
Takeaway: When IAM roles “don’t work,” always verify metadata reachability before touching permissions. This happens because the application inside the instance cannot access the instance metadata service, even though the IAM role itself is correctly attached. In Amazon Web Services, credentials forRead more
Takeaway: When IAM roles “don’t work,” always verify metadata reachability before touching permissions.
This happens because the application inside the instance cannot access the instance metadata service, even though the IAM role itself is correctly attached.
In Amazon Web Services, credentials for an instance role are delivered through the metadata endpoint at
169.254.169.254. If that endpoint is blocked, disabled, or requires IMDSv2 while your SDK expects IMDSv1, the SDK reports missing credentials.Start by checking whether metadata access is enabled on the instance. Then verify whether IMDSv2 is enforced and whether your SDK version supports it. You can quickly test access from the instance with:
curl http://169.254.169.254/latest/meta-data/
If this fails, inspect security hardening scripts, iptables rules, or container network settings that may block the endpoint.
A common mistake is assuming the IAM role alone guarantees access. It does not—metadata access must also be available.
See less